this post was submitted on 18 Oct 2023
        
      
      1 points (100.0% liked)
      Lisp
    61 readers
  
      
      3 users here now
      
        founded 2 years ago
      
      MODERATORS
      
    you are viewing a single comment's thread
view the rest of the comments
    view the rest of the comments
It may sound bad, but I agree. The split between tools deps and lein just creates confusion and friction with newcomers, who start using clojure with deps, but inevitably run into a library that's built with lein. Also, mixing lein dependencies into a tools deps project breaks things like overriding transitive dependencies.
I know tools.deps and Leiningen/Maven have subtly different dependency resolution logic, but is this a problem in practice? I've never run into myself, and surely its trivially fixed by making the dependencies explicit.
Apologies, I don't have a lot of time to dig into this further and my memory has faded since I last ran into this, but I remember at least two issues:
when I want to use a
:git/urlversion of a library that's built with lein, I have to use:deps/manifest :depsand I believe that there's basically no way forcljto know about the dependencies of the library that way (keep in mind thatpom.xmlis not usually checked into git for these libraries). The way I used this was to override thefi.metosin/reitit-openapitransitive sub-module offi.metosin/reitit(which I got from clojars), so I already had all the other dependencies in the classpath.I had a private fork of a library that was built with lein and was relying on build steps that could have been solved
:deps/prep-libif the lib was using tools depsThe reasons I had to use git refs and private forks are fixed now in the upstream of the libraries so I don't have my workarounds anymore.