TDEPS-74 seems to get to the heart of it. OK, I guess I'll go vote for it!

@alexmiller @arrdem was offering a patch for the local/root issue I believe...

well I’ve thought about it a lot and haven’t come up with a solution I’m happy with

If the tools.deps reader converted paths (from :paths, :extra-paths, and :local/root -- and maybe others?) from relative to absolute, based on the location of the deps.edn file in which they occur, would that solve the problem?

I don’t think so

(or, rephrased, at what point does tools.deps convert paths to absolute ones -- they are absolute in the classpath at the end)

the extension does it when it resolves the paths for a dep

but it’s really about what the “current directory” means when you are resolving a transitive dep by relative path - currently nothing is shifting that context so you always have the root dep context

Ah, and paths can be in both the system deps and the per-user deps and of course you don't want those resolved against the file they're defined in... yeah...

And by the time you've collapsed all the deps down, you've lost that context, right?

yeah. we actually conceived local deps primarily as working primarily with absolute paths - all the stuff people are doing with relative paths and monorepos is somewhat emergent

So for https://github.com/fundingcircle/lein-modules, we added a “//” notation somewhat stolen from pantsbuild - the idea was that paths which were not “//” prefixed were treated as relative and just passed around, “//” prefixed paths were treated as being absolute with respect to the project.clj the path occurred in - for us implicitly the “root” project.clj of the repo which emulates the meaning of “//” in Google Blaze derived systems where “//” is repo root when referring to build target names.

That’s worked out OK at best for us.