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.
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. >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. 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? On Fri, Jan 5, 2018 at 2:39 PM Alex Miller <a...@puredanger.com> wrote: > On Fri, Jan 5, 2018 at 1:20 PM, Gary Trakhman <gary.trakh...@gmail.com> > wrote: > >> Congrats on the release! It's exciting to see this vision move forward. >> Wondering if the logical next step is the npm style of trees of duplicate >> transitive git deps. In general, how is this going to work for transitive >> deps? >> > > tools.deps has the ability to read a file-based manifest in a git dep (or > a local dep) and traverse its transitive dependencies. This works now for > deps.edn based libraries and can be extended for other manifest types. > > I have started work on a pom.xml manifest reader. lein is harder to do > right, but maybe easy to do badly. :) There are still some things to work > out wrt how manifest readers like this are dynamically found and loaded; > currently they have to be "in the box" but I see that's not the final end > state. > > > -- > 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.
