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?
Just to be sure I understand:
credois dev dependency so it is not installed in projects using
spaceboyframework. So you are concerned just with this repo and conveniences for
- Currently there is no CI/CD configured.
- What do you mean by "warnings about recompilation"? I don't see any warnings locally. Could you post some example?
I would like to keep
credoas dev dependency because it makes the local configuration easier (it is installed automatically vs. user needs to install it globally to be able to use it). On the other hand it is pretty small benefit so if it is causing some issues or slowdowns (
credocan take a long time to compile) I am willing to consider alternatives :)
BTW how did you found this project? Are you using it for your capsule or just exploring? I am preparing to announce it on Gemini mailing list soon so if you have some experience using this project I would love to hear it. Also any suggestions or pinpoints are welcomed! You can fill and todo here or write me an email at
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.
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!
Interesting points about
credo. I am actually full-time Elixir developer and in our company we keep Credo as dev dependency so I just used this configuration I am used to. But we don't have any open-source public library and your points makes sense. I will do a bit more research on this topic but now I am more inclined to remove