On Friday, January 5, 2018 at 2:08:50 PM UTC-6, Gary Trakhman wrote: > > Specifically, I'm asking about how to resolve duplicate transitive > dependencies to actual code, possibly referring to the same lib repo at > different git hashes, or different git repos. >
Ah, good question. The answer is that you need some way to detect version differences and resolve them. Fortunately, this is the identical problem you have in Maven and the solution is effectively the same - pick the newer one. In a git context this means "the commit that has the other as an ancestor". With a growth mindset <https://www.youtube.com/watch?v=oyLBGkS5ICk>, this is a safe choice. If two versions do not share a ancestor/descendant lineage, then your build is broken and you will be required to fix it. > I think you answered, 'how do you get a single graph of deps nodes given > different kinds of deps'? > > For example: > A->B->C#some_tag > A->D->C#other_tag > > So, assuming you use a lot of git deps, which I think is the long-term > intent here based on the messaging, resolving those pointers to actual > loaded code is a potential problem that needs to be addressed somehow. I > mentioned one way, which is to have multiple copies of a lib loaded > automatically. > Not doing that. > > From what I can tell so far, it seems like you can override a dep's > specific transitive deps, but that sounds painful when scaled out over > number of deps and how many more commit hashes exist than maven release > tags for each lib. > Either the descendant-most version will be chosen or your deps are broken and will fail to compute a classpath. Additionally, most Maven artifacts (certainly most in Maven central or clojars) contain SCM metadata about the git url and rev that they represent. This gives us the ability to compare git deps with Maven deps (via their git rev) and apply the same logic. Not yet done, but coming soon... > Another way to do it might be to make the git repo url+branch itself could > be part of the namespace var mapping, but that seems far off based on the > way clojure namespaces currently work, and doesn't cover the common case > (at least it's what we're used to with maven) of just resolving a single > version for each dep. > > Is there some existing design thought along these lines that I've missed? > -- 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.
