leiningen dependency management

[Sven Richter]

Hi,

I have a library A that I use in project B. Now, library A makes use of plumatics schema, as well as project B. I wonder what the best practice is here. 

Include schema in library A's dependencies? Or only declare a dev-dependency on schema in library A?

If I declare a dev-dependency I require every project that depends on library A to include schema as a dependency, otherwise it will not work (I have seen that with database libs for instance). I find that a bit unlucky, because one might end up referring a lot of libs that other libraries depend on.

Or, include it as a direct dependency in library A. But then strange things may happen as I had it with schema. Library A included schema v 1.0.5 and project B schema v 1.0.3. 

Now when I executed code in project B I had a weird schema error saying that something in the schema is wrong, during compile time. In the end it turned out that I have to require schema v 1.0.5 in project B too to make it work. This is even more troublesome, as I make every project, that depends on my library, depend on a transitive dependency in a specific version.

Looking at gradle for instance there is a configuration called 'providedCompile' which means it is used for compilation of the library, but not a transitive dependency if I include that library. Is there something similar for leiningen?

Best Regards,

Sven

[James Reeves]

Include it as a dependency.

Maven dependency resolution is rather strange, and Leiningen inherits this strangeness. Effectively what matters is how "close" the dependency is. So dependencies in your project file take precedence over the dependencies of your dependencies, and so forth.

Maven does have a way of providing a version range, but last time this was looked at the general consensus was that it was too broken to be of use. Version ranges are not overridable, and open-ended ranges always use the latest version, even if it's a SNAPSHOT.

- James

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Ziltener]

Hi Sven,

When you're sure the project depending your library does also has a dependency on a third library, it's best to use the ":provided" profile, rather than declaring it in the :dev profile. In your case there are two possible solutions:
1. the dependency higher up wins. So if you declare the schema dependency above the dependency on A, this should work.
2. modify the dependency vector in B's profile.clj so that it's something like [A "0.1.0" :exclusions [schema]]. See https://github.com/technomancy/leiningen/blob/stable/sample.project.clj#L48 for an example.

I hope this helps you.
zilti

[Sven Richter]

Hi,

Thanks for your responses. I will go and try the :provided profile and see how it works out.

Thanks,

Sven

[Chris Price]

We run into this sort of thing quite a bit.  Our solution so far has been:

1. Always use `:pedantic? :abort` in the project file.  It can be annoying, but we've found that's much better to get annoying errors about version conflicts at build time than to get cryptic failures at runtime, such as the one that you described with schema.
2. Any time `:pedantic?` surfaces a conflicting transitive dependency between two libraries, we add an explicit dependency for the transitive dependency to resolve the conflict.  We usually have a section at the top of our dependencies list reserved for these transitive dependency resolutions, with some comments around it explaining that these aren't "normal" dependencies.  Doing it this way seems to give us more warning when new versions of upstream libraries come into use, whereas `:exclusions` is more likely to silently ignore those situations.

I've also been hacking on support for "managedDependencies" (https://github.com/technomancy/leiningen/issues/2067), which would allow you to specify common dependency versions in a parent project file and hopefully eliminate some of the dependency-version-whack-a-mole that seems to creep in when you start working with a large number of libraries.