Suggestion for removing credo from dependencies

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?

Assigned to
7 months ago
7 months ago

~sgiath 7 months ago

Just to be sure I understand:

  1. credo is dev dependency so it is not installed in projects using spaceboy framework. So you are concerned just with this repo and conveniences for Spaceboy developers?
  2. Currently there is no CI/CD configured.
  3. 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 credo as 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 (credo can 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 sgiath@pm.me

~arpunk 7 months ago

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.

~arpunk 7 months ago

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!

~sgiath 7 months ago

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 credo as dependency.

Register here or Log in to comment, or comment via email.