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
credoto find out code enhancements and refactor oportunities, but I usually tend to annotate those using my local
credoinstallation. The usefulness of
credocomes when we pass formatting/credo to each pull request we intent to merge. We archieve that by enabling local
credoin our CI pipeline which is triggered by each PR submitted to the repository.
Maybe people already have the same
credoanalysis 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
spaceboymailing list, cheers!
I'm saying that if one wants to develop the
spaceboysource code then I need to remove
credofrom my installed mix archives because the
spaceboyrepo itself declares the dependency. If I keep both versions then everytime I need to recompile
spaceboydependencies I might end up recompiling
credowhich throws warnings because the package is already installed as a mix archive.
credois 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
credoin 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
credois 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
credowill make warnings about recompilation go away. WDYT?