my team and i have come across https://ask.clojure.org/index.php/11711/set-mvn-local-repo-via-alias "Set mvn/local-repo via alias" (it would help us manage CI caching while not duplicating deps for devs), and i see that the corresponding jira ticket doesn't have a patch. it's not exactly blocking us but it would be really nice for those of us who have ~60 different clojure apps/libraries cloned locally. is this something you'd accept a patch for?
tbh, I'm not sure about this one. I logged it to track the need and interest. I guess I'd like to understand your problem more. why is it not sufficient to use the standard local-repo?
for each repo, i have a deps.edn file which specifies only the dependencies for that service or library, and then i have a git submodule with a tools/deps.edn that holds all of the dev-oriented aliases (linting, formatting, jar building, etc). this allows for sharing tools across the whole org.
i have a Makefile which calls all of the appropriate clj -Sdeps tools/deps.edn -M:clj-kondo --lint dev:src:test etc for me, and I want to be able to specify :mvn/local-repo in my CI pipeline so I can properly cache dependencies between runs (Gitlab CI can't cache $HOME/.m2/repository).
the issue comes from using -Sdeps already to specify a dev-focused deps.edn, and not wanting to include :mvn/local-repo when working locally.
if we had a single repo, using :mvn/local-repo would be fine because there would be no duplication. but when we have somewhere between 60 and 200 repos, and devs are expected to work on many of them, the number of copies of a given library grows quite large.
being able to put :mvn/local-repo into an alias would allow me to say clj -Sdeps tools/deps.edn -M:ci:foo
is "Gitlab CI can't cache $HOME/.m2/repository " then driving the problem? (and I find that hard to believe)
https://docs.gitlab.com/ci/caching/#how-cache-is-different-from-artifacts > Both artifacts and caches define their paths relative to the project directory, and canβt link to files outside it.
this is not a problem for other CI pipelines i've worked with (such as Github)
there seem to be answers to this in the links above, so I don't understand
the answers don't apply to clojure. tools.deps doesn't rely on MAVEN_OPTS, does it?
like this example from Gitlab: https://gitlab.com/gitlab-org/gitlab-ci-yml/-/blob/master/Maven.gitlab-ci.yml
why does tools.deps need to?
(if it does, maybe that's another possible solution)
the answer you're poitning at rests on MAVEN_OPTS being used when downloading maven dependencies
MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository"
is the suggested solutionthe clojure equivalent is -Sdeps {:mvn/local-repo ".m2/repository"} which would work if we weren't already relying on -Sdeps tools/deps.edn
oh, the problem being that this is a project-relative dir, not ~/.m2/repository
if i'm understanding you correctly, yes
putting this in an alias creates many new problems with hard to define answers, potentially at odds with current and future features, which is why I am quite hesitant to go that direction. Really, the local-repo should not be part of deps.edn at all, it should be an environmental concern controlled outside this context, so I am a lot more interested in that kind of solution. For example, creating a new env var or system property entirely.
that would also solve this, yeah
if you wanted to look at a patch for something like CLJ_MAVEN_LOCAL_REPO, I'd be interested in that. I think the only place that would need to change is https://github.com/clojure/tools.deps/blob/448b8120eb676badc92b85687dc88761f8864a8f/src/main/clojure/clojure/tools/deps/util/maven.clj#L173
cool, i'll write up a patch for that to see how it looks/feels
I guess we can also consider system property as an option (we already have a way to pass system properties via CLJ_JVM_OPTS env var).
system property benefits are that it's easier to test (can set and unset), and in-process uses can set inside the Java program
I guess looking at that line of code again, you could do what you want now by export CLJ_JVM_OPTS=-Duser.home=.
the default local repo is then ./.m2/repository
oh interesting. i assume that could change other parts of an app, if it happens to rely on user.home being $HOME?
yes, I think having an explicit property would be better, but you could try this now to see if it works for you
changing user.home will also change assumptions about your user-level ~/.clojure/deps.edn config, but I assume it's unlikely you are dependent on that
I updated the jira with the system property direction, patch welcome
cool, thanks