Re: leiningen dependency management
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.
Re: leiningen dependency management
Hi, Thanks for your responses. I will go and try the :provided profile and see how it works out. Thanks, Sven Am Samstag, 9. April 2016 02:51:15 UTC+2 schrieb 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 > > Am Freitag, 8. April 2016 21:36:50 UTC+2 schrieb 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 >> > -- 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.
Re: leiningen dependency management
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 Am Freitag, 8. April 2016 21:36:50 UTC+2 schrieb 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 > -- 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.
Re: leiningen dependency management
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 On 8 April 2016 at 20:36, 'Sven Richter' via Clojure < clojure@googlegroups.com> 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. > -- 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.
