Currently, no, but that’s something we’ve been talking about lately

I think it needs some consideration on both export and import sides

Like a lib would want to say what aliases it exports, and I think a downstream user might want to choose what it imports too

agree… in this particular case I am debating between exporting these two dependencies from my project: https://github.com/mentat-collective/clerk-utils/blob/main/deps.edn#L15-L20 and telling the user to bring their OWN clerk version, but wincing at the “please include both of these and make sure the SHA always matches”

The case I was looking at is very similar

oh! while I’ve got you, I had a Q - how does dependency resolution work between 1. git deps (if I include one and someone overrides it, presumably that works) 2. a git dep and the clojars version of that dep — for this one I assume there is no dependency resolution?

in my case this feature only works with git dependencies (the render dep is not available as a jar), so I dodge the problem. but I was was wondering if there were some way to tell tools.deps “I publish this code as a jar under this org/project, version == tag, please resolve that way” or something like that

at the moment, there is no comparison logic for git to mvn

so it will just fail and say you need to be explicit at top level about which one to use

but, there is a hole with a todo where this logic could go. maven jars have a pom, which has scm info, and it should actually be possible to compare the published git scm info for a jar and the git dep scm info and decide which was "newer", so maybe in the future