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. On Friday, April 8, 2016 at 12:36:50 PM UTC-7, Sven Richter wrote: > > 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 > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
