clojure-dev

2026-01-16T19:24:14.028789Z

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?

Alex Miller (Clojure team) 2026-01-16T19:33:14.861089Z

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?

2026-01-16T19:50:21.290959Z

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.

2026-01-16T19:51:44.145879Z

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.

2026-01-16T19:52:50.218409Z

being able to put :mvn/local-repo into an alias would allow me to say clj -Sdeps tools/deps.edn -M:ci:foo

Alex Miller (Clojure team) 2026-01-16T19:55:03.963249Z

is "Gitlab CI can't cache $HOME/.m2/repository " then driving the problem? (and I find that hard to believe)

2026-01-16T19:56:21.943489Z

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.

2026-01-16T19:57:11.204779Z

this is not a problem for other CI pipelines i've worked with (such as Github)

Alex Miller (Clojure team) 2026-01-16T19:58:02.509029Z

there seem to be answers to this in the links above, so I don't understand

2026-01-16T19:58:44.028889Z

the answers don't apply to clojure. tools.deps doesn't rely on MAVEN_OPTS, does it?

Alex Miller (Clojure team) 2026-01-16T19:58:44.969359Z

like this example from Gitlab: https://gitlab.com/gitlab-org/gitlab-ci-yml/-/blob/master/Maven.gitlab-ci.yml

Alex Miller (Clojure team) 2026-01-16T19:59:25.506849Z

why does tools.deps need to?

Alex Miller (Clojure team) 2026-01-16T19:59:42.801839Z

(if it does, maybe that's another possible solution)

2026-01-16T19:59:51.721739Z

the answer you're poitning at rests on MAVEN_OPTS being used when downloading maven dependencies

2026-01-16T20:00:41.217339Z

MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository"
is the suggested solution

2026-01-16T20:02:19.012629Z

the clojure equivalent is -Sdeps {:mvn/local-repo ".m2/repository"} which would work if we weren't already relying on -Sdeps tools/deps.edn

Alex Miller (Clojure team) 2026-01-16T20:03:22.353899Z

oh, the problem being that this is a project-relative dir, not ~/.m2/repository

2026-01-16T20:04:05.198429Z

if i'm understanding you correctly, yes

Alex Miller (Clojure team) 2026-01-16T20:08:09.074559Z

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.

2026-01-16T20:08:31.137359Z

that would also solve this, yeah

Alex Miller (Clojure team) 2026-01-16T20:10:59.378609Z

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

πŸ‘ 1
2026-01-16T20:11:52.092639Z

cool, i'll write up a patch for that to see how it looks/feels

Alex Miller (Clojure team) 2026-01-16T20:17:15.328979Z

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).

Alex Miller (Clojure team) 2026-01-16T20:22:49.069279Z

system property benefits are that it's easier to test (can set and unset), and in-process uses can set inside the Java program

Alex Miller (Clojure team) 2026-01-16T20:27:34.897929Z

I guess looking at that line of code again, you could do what you want now by export CLJ_JVM_OPTS=-Duser.home=.

πŸ‘€ 1
Alex Miller (Clojure team) 2026-01-16T20:28:54.546619Z

the default local repo is then ./.m2/repository

2026-01-16T20:34:03.174029Z

oh interesting. i assume that could change other parts of an app, if it happens to rely on user.home being $HOME?

Alex Miller (Clojure team) 2026-01-16T20:42:36.034179Z

yes, I think having an explicit property would be better, but you could try this now to see if it works for you

πŸ‘ 1
Alex Miller (Clojure team) 2026-01-16T20:43:54.575309Z

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

Alex Miller (Clojure team) 2026-01-16T20:56:39.741399Z

I updated the jira with the system property direction, patch welcome

πŸ‘ 1
2026-01-16T20:56:51.766429Z

cool, thanks