I'm sorry, I think I missed the second part of your reply.

I think it really boils down to contributions; Most of the time we run credo to find out code enhancements and refactor oportunities, but I usually tend to annotate those using my local credo installation. The usefulness of credo comes when we pass formatting/credo to each pull request we intent to merge. We archieve that by enabling local credo in our CI pipeline which is triggered by each PR submitted to the repository.

Maybe people already have the same credo analysis by using LSP + Visual Studio? maybe they use elixir_ls + Emacs (like I do). This is why I opt for not including such tooling on the dependencies itself.

As for the finding, I was looking for Elixir codebases in sr.ht and found spaceboy, good project, I might use it for my Gemini pods if I find the time to migrate my current webserver so I can serve both Gemini/HTTP on the same app in Elixir. I already subscribed to the spaceboy mailing list, cheers!

I'm saying that if one wants to develop the spaceboy source code then I need to remove credo from my installed mix archives because the spaceboy repo itself declares the dependency. If I keep both versions then everytime I need to recompile spaceboy dependencies I might end up recompiling credo which throws warnings because the package is already installed as a mix archive.

credo is useful for the individual developer, not the whole project. I also meant by CI/CD that it would be the only case when I would enforce credo warnings and still you can manage that without listing credo in the project dependencies.

The suggestion comes because this is often a mistake we correct in our codebases and not a best-practice when you look at the other codebases such as Ecto, Phoenix, Nerves, etc.

Most of the time credo is installed as stand-alone mix archive. Is also a developer tool, so in case we need the warnings we can install it stand-alone on the CI/CD pipelines if needed. Removing credo will make warnings about recompilation go away. WDYT?