Why interest in porting "Git Deps for Clojure" to lein, when there's lein-voom?

I’ve badly neglected to split off utils/specs into private git repos, as deps. So lein-voom looks attractive & I plan to try it soon.

But Cognitect recently announced git deps, and people asked about lein adopting it. Skimming docs, both seem fine. (Unlike lein-git-deps, which doesn’t fit my use-case since it doesn’t support private git repos.)

So, why the interest in supporting it in lein, when lein-voom exists?

  • Usability (removes lein-voom’s build-deps step)?
  • Generality (straightforward support for maven, git & local coordinates)?
  • Robustness (happens to work better in practice)?

Oh wait, duh. With lein-voom, you still have to supply Maven coordinates. Which probably implies I still need to publish artifacts to a private Maven repo? Defeating much of the point for me?

Guess I’d better test…

Perhaps I’m missing something, so apologies in advance. What I like about tools.deps is the ability to split out dependency information from building and scripts. There are tools available in Boot that I like, and similarly with Leiningen. Sometimes I want to create a custom script that relies on the dependencies in my project, and don’t want to write a Boot task or add something to Leiningen: The Clojure CLI tools and tools.deps allows me to do that.

As it is, I currently write a deps.edn file first, and use @seancorfield’s boot-tools-deps if I want to use Boot.

If there’s a tool I want to use with Leiningen, I’ll duplicate the deps there, but that always grates on me. (I seem particularly susceptible to bugs that arise from not keeping things DRY.) Rick Moynihan’s lein-tools-deps looks to do similar things and something I hope to use more in the future: as it is now, it’s still—as described—a work in progress and has bugs that prevents it from working out of the box for me at this point, but I look forward to when it’s solid.

Especially since deps.edn is a simple data file, tools like lein-voom can easily manipulate and update it, and everything leveraging it can take advantage of the common location for dependency information.

In my own work I’m trying to push a deps-first approach as far as I can. It seems a logical common integration point for general tooling.

1 Like