librelist archives

« back to archive

Re: [leiningen] Order dependency of dependencies

Re: [leiningen] Order dependency of dependencies

From:
Phil Hagelberg
Date:
2013-08-29 @ 20:58
Chris Perkins writes:

> That is, I thought that when conflicting versions of a transitive
> dependency were found, the highest-numbered one would be picked. I just
> discovered today that this is not the case, and that the first-found
> version seems to be picked.

The basic logic is that the "closest" to the root (or least transitive)
dependency wins, but if two have the same level of transitivity, the
first one wins.

> Is this intentional? Should I just add exclusions to get around this?
> (re-ordering dependencies in my project file can fix some of the problems
> I'm having, but seems like an unwinnable game in the long run).

It's intentional that we don't diverge from the logic of Maven. However,
if you're concerned about your dependencies it's highly recommended to
run `lein deps :tree` to ensure you're getting the dependencies you're
expecting. Using an explicit :exclusions clause when there is a conflict
is a good idea. You can set `:pedantic :warn` in project.clj to get
conflict warnings whenever you run code so you don't have to go out of
your way and run `lein deps :tree` to get notified of them.

-Phil

Re: [leiningen] Order dependency of dependencies

From:
Eric Arthen
Date:
2013-08-29 @ 21:06
I don't think Maven does "first found" nor does it do highest found.

As I recall it looks at what is required closest to the current project.

So if you list dependency  A 1 and B, and then B lists A 2, maven will take
A 1 since you directly listed it.

(but test to make sure i got that right)

Eric


On Thu, Aug 29, 2013 at 4:58 PM, Phil Hagelberg <phil@hagelb.org> wrote:

>
> Chris Perkins writes:
>
> > That is, I thought that when conflicting versions of a transitive
> > dependency were found, the highest-numbered one would be picked. I just
> > discovered today that this is not the case, and that the first-found
> > version seems to be picked.
>
> The basic logic is that the "closest" to the root (or least transitive)
> dependency wins, but if two have the same level of transitivity, the
> first one wins.
>
> > Is this intentional? Should I just add exclusions to get around this?
> > (re-ordering dependencies in my project file can fix some of the problems
> > I'm having, but seems like an unwinnable game in the long run).
>
> It's intentional that we don't diverge from the logic of Maven. However,
> if you're concerned about your dependencies it's highly recommended to
> run `lein deps :tree` to ensure you're getting the dependencies you're
> expecting. Using an explicit :exclusions clause when there is a conflict
> is a good idea. You can set `:pedantic :warn` in project.clj to get
> conflict warnings whenever you run code so you don't have to go out of
> your way and run `lein deps :tree` to get notified of them.
>
> -Phil
>



-- 
Eric Leventhal Arthen  |  Principal Software Engineer
Brightcove, Inc. http://www.brightcove.com/
earthen@brightcove.com