It makes sense, although I’ve mostly thought about solving this in terms of local deps that also have awareness of being in a git context

Although it depends a bit what consumption patterns you are targeting for users

This is why Polylith uses :local/root for everything instead of trying to deal with git deps.

@U064X3EF3 That would be indeed more transparent. Are there any technical constraints preventing that sort of implementation? @U04V70XH6 But then what happens if you want to make some parts of the repo easily available for external users? This is my main concern with the setup above.

> easily available for external users What do you mean by this? Who are the external users? Do you expect them to git-depend on your monorepo or via some other approach? With Polylith, the projects can be git-depended on -- that's how the various parts of the Polylith tooling are exposed...

Git-depending indeed. If a project requires :local/roots, wouldn't that be problematic when attempting to consume it as a gitlib?

No. The whole repo is checked out but :deps/root determines which "project" to use so the local deps all work because they're relative.

That's exactly how the poly and polyx tools work: one repo, multiple :deps/root values.

Ah, I might be misremembering but I remember encountering trouble when mixing gitlibs with :local/root. Experimenting a long time ago though, either things have changed or my memory is flawed.

Happy to help if you try it out and get stuck. As far as I know, it's worked this way for at least a few years...

One last that should put my mind at ease 🙏 What happens with the version resolution of common :local/roots if a user depends on 2 projects but with different SHAs? I think that's the sort of things I might have had trouble with at the time.

If the versions are comparable, tools.deps will pick the most recent version.

(`:local/root` isn't really relevant to that -- any transitive path to the same lib with different versions is treated the same way)

the place that can problematic is if you end up with transitive deps on the same sub-project, one via local root, one via git dep, which right now will not compare

Right, and so we circle back to your original answer I believe. Thank you both!

But if the monorepo uses :local/root deps and everyone outside the repo uses :git deps that won't happen (at least with Polylith).

Oh wait... I get it... tools.deps would not consider them needing to be compared because the libname would be different, even tho' multiple libs resolve to the same git repo?

So tools.deps thinks they're different libs -- even tho' they are the same gitlib -- and wouldn't cause one to be treated as newer than the other... and so if those separate libs had overlapping :local/root deps, you could end up with an arbitrarily-chosen version of the common code due to classpath ordering...?

that is also a possible problem, but I'm really referring to: foo/a {:git/url "..." :git/sha "..." :deps/root "subA"} foo/b {:local/root "../b"} ext/c foo/b {:git/url "..." :git/sha "..." :deps/root "subB"}

can't compare the two foo/b references to select one

foo/b needs to be able to act in both a local relative sense to foo/a but also have it's own git context. I think that's a solvable problem but it needs some thinking

OK, so that specific problem "can't happen" with Polylith specifically because outside projects can depend on specific projects/foo/* parts of the monorepo and while those can have :local/root deps, nothing else in the repo can depend on the projects/foo/* parts via :local/root deps. But, just to confirm my understanding, foo/a and foo/b would not be considered for newer/older selection even if they both had identical :git/url values and different :git/shas? So you'd get the same repo, checked out at two different SHAs, and treated as completely separate libs.

different lib names are never compared, they are treated as different libs