Clojure Q&A - Recent questions and answers in tools.deps

Answered: Concurrency bug in tools.deps use of Aether/Maven libs?

Mon, 27 Jul 2026 22:04:28 +0000

In Clojure CLI 1.12.5.1664 I have moved tools.deps to use a single shared context/system/session instead of creating and caching one per thread. The previous mode was attempting to increase isolation when Maven was handling this poorly. In the newer version of these libs, they have made these interface support concurrency better and I believe this will be better.

Answered: How to access non-jar artifacts (aar, zip) downloaded via tools.deps in build.clj?

Wed, 24 Dec 2025 18:03:56 +0000

In tools.build you can find these paths in the :libs key of the basis when you build it, so that would give you the path.

You can then use unzip in the tools.build api to help unzipping it. See https://clojure.github.io/tools.build/clojure.tools.build.api.html#var-unzip

`create-basis` silently accepts missing aliases

Tue, 10 Jun 2025 00:57:37 +0000

In this scenario, the alias for create-basis was incorrect, preventing security deps overrides from being applied. For 2 years clojars was deployed with these vulnerable deps.

In this case, I proposed to inline the alias into :deps. However there may be other scenarios where a tools.deps change might be helpful to catch these mistakes earlier, for example a warning or error.

unable to use add-lib on io.github.borkdude/grasp

Fri, 17 Jan 2025 14:15:15 +0000

repro:

user=> (add-lib 'io.github.borkdude/grasp {:mvn/version "0.1.4"})
Execution error (ExceptionInfo) at clojure.tools.deps.interop/invoke-tool (interop.clj:81).
Could not find artifact org.clojure:clojure:jar:1.11.0-rc1

This seems strange to me. The deps edn of grasp: https://github.com/borkdude/grasp/blob/master/deps.edn

{:deps {org.babashka/sci {:mvn/version "0.3.2"}}
 :aliases {:native {:jvm-opts ["-Dclojure.compiler.direct-linking=true"]
                    :extra-deps {org.clojure/clojure {:mvn/version "1.10.2-alpha3"}
                                 org.clojure/tools.cli {:mvn/version "1.0.194"}}}
           :test {:extra-paths ["test"]
                  :extra-deps {org.clojure/clojure {:mvn/version "1.11.0-rc1"}
                               cognitect-labs/test-runner
                               {:git/url "https://github.com/cognitect-labs/test-runner"
                                :sha "cb96e80f6f3d3b307c59cbeb49bb0dcb3a2a780b"}}
                  :main-opts ["-m" "cognitect.test-runner"]}}}

It's surprising to me that deps in the :test alias would cause issues.

EDIT: seems to work now. Here's the stacktrace from a socket repl where i first encountered it

user=> (add-lib 'io.github.borkdude/grasp {:mvn/version "0.1.4"})
Execution error (ExceptionInfo) at clojure.tools.deps.interop/invoke-tool (interop.clj:81).
Could not find artifact org.clojure:clojure:jar:1.11.0-rc1
user=> nil
user=> (pst)
ExceptionInfo Could not find artifact org.clojure:clojure:jar:1.11.0-rc1 {:via [{:type clojure.lang.ExceptionInfo, :message "Could not find artifact org.clojure:clojure:jar:1.11.0-rc1", :data {:lib org.clojure/clojure, :coord {:mvn/version "1.11.0-rc1", :deps/manifest :mvn, :dependents [io.github.borkdude/grasp], :parents #{[io.github.borkdude/grasp]}}}, :at [clojure.tools.deps.extensions.maven$get_artifact invokeStatic "maven.clj" 167]}], :trace [[clojure.tools.deps.extensions.maven$get_artifact invokeStatic "maven.clj" 167] [clojure.tools.deps.extensions.maven$get_artifact invoke "maven.clj" 155] [clojure.tools.deps.extensions.maven$eval1225$fn__1228 invoke "maven.clj" 178] [clojure.lang.MultiFn invoke "MultiFn.java" 244] [clojure.tools.deps$download_libs$fn__802$fn__803 invoke "deps.clj" 466] [clojure.lang.AFn applyToHelper "AFn.java" 152] [clojure.lang.AFn applyTo "AFn.java" 144] [clojure.core$apply invokeStatic "core.clj" 667] [clojure.core$with_bindings_STAR_ invokeStatic "core.clj" 1990] [clojure.core$with_bindings_STAR_ doInvoke "core.clj" 1990] [clojure.lang.RestFn invoke "RestFn.java" 428] [clojure.lang.AFn applyToHelper "AFn.java" 156] [clojure.lang.RestFn applyTo "RestFn.java" 135] [clojure.core$apply invokeStatic "core.clj" 671] [clojure.core$bound_fn_STAR_$fn__5837 doInvoke "core.clj" 2020] [clojure.lang.RestFn invoke "RestFn.java" 400] [clojure.lang.AFn call "AFn.java" 18] [java.util.concurrent.FutureTask run "FutureTask.java" 317] [java.util.concurrent.ThreadPoolExecutor runWorker "ThreadPoolExecutor.java" 1144] [java.util.concurrent.ThreadPoolExecutor$Worker run "ThreadPoolExecutor.java" 642] [java.lang.Thread run "Thread.java" 1583]], :cause "Could not find artifact org.clojure:clojure:jar:1.11.0-rc1", :data {:lib org.clojure/clojure, :coord {:mvn/version "1.11.0-rc1", :deps/manifest :mvn, :dependents [io.github.borkdude/grasp], :parents #{[io.github.borkdude/grasp]}}}}
	clojure.tools.deps.interop/invoke-tool (interop.clj:81)
	clojure.tools.deps.interop/invoke-tool (interop.clj:41)
	clojure.repl.deps/add-libs (deps.clj:48)
	clojure.repl.deps/add-lib (deps.clj:59)
	clojure.repl.deps/add-lib (deps.clj:59)
	user/eval310956 (NO_SOURCE_FILE:320)
	user/eval310956 (NO_SOURCE_FILE:320)
	clojure.lang.Compiler.eval (Compiler.java:7700)
	clojure.lang.Compiler.eval (Compiler.java:7655)
	clojure.core/eval (core.clj:3232)
	clojure.core/eval (core.clj:3228)
	user/eval257807/fn--257810 (NO_SOURCE_FILE:8)

Answered: How can I ensure that a private Maven coordinate cannot be shadowed in a public repository?

Fri, 01 Nov 2024 18:03:32 +0000

The main current answer is that the public repos are trying to prevent this.

There are two public repos included in the root deps.edn - Maven Central and Clojars. All other repos must be explicitly included in the top-level deps.edn in use (transitive deps.edn repos are ignored - this differs from pom.xml).

Maven Central has policies to encourage using reverse domain names and/or trademarked names that you control, with requirements for verification. Clojars is now doing similar things, but their naming policies are somewhat laxer and I don't know the current state of everything they are doing.

The signing key stuff is problematic for lots of reasons (clojars doesn't require, keys must be registered - how do you know if the key you find is one you should trust, etc). This requires a lot of manual intervention. I have been following SLSA which I think is taking a smarter approach to provenance and verification. Would love to spend some time really working on how to integrate something like this into both our Clojure build systems and our dependency management tools to work together. Especially for open source libraries distributed as source, we should be able to hash+compare the actual source and relate it to a commit - Clojure's options are WAY BETTER than compile-to-class langs that make new artifacts different than the original source.

Hoping to spend some time on this kind of stuff next year.

Answered: clj -X:deps find-versions prefers git deps if both git and mvn exist

Tue, 17 Sep 2024 02:44:25 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-268

Answered: Allow specifying aliases in coordinates that point to deps.edn projects

Thu, 08 Aug 2024 10:23:08 +0000

I just stumbled upon this very same old tools.deps issue myself with a Polylith workspace recently, when I decided to factor out a few sub-projects into Polylith workspaces of their own. But, since poly has a convention to keep all dev-time dependencies under the :dev alias, things didn’t click (quite obviously), so I had to duplicate them under the :deps key.

I’m now thinking about patching the tools.deps and using a patched version locally solely for this project.

Answered: Transitive dependency resolution skipping some libs

Tue, 27 Feb 2024 23:05:38 +0000

This description doesn't make sense to me - in both branches "general/some-lib :mvn/version 1.0" exists and should be included with its own transitive deps, so it feels like something has been lost here in the process of redacting. In particular, I'm also wondering if there are :exclusions at any point in the tree.

It would be helpful if you could narrow the deps tree to whatever the equivalent is above, capture a trace with -Strace and send a gist of the trace.edn (redacted if necessary). I understand if redaction is necessary, but the closer I can get to the original, the easier it will be for me to understand what's happening. You can send dm on Clojurians Slack or email too if that's better.

You might also find this page helpful, particularly the orphans section:
https://clojure.org/reference/dep_expansion

Answered: Improve error message for tools.deps when m2 permissions do not allow write

Mon, 29 Jan 2024 18:31:57 +0000

This is a common issue when you mount ~/.m2 and friends into Docker using a volume in order to avoid downloading artifacts all over again. If something gets downloaded inside docker anyhow, that file might be written as root into the users home directory. I also run into this at least a couple of times over the years. Last time last week. :slightly_smiling_face: Not a Docker expert either, and I may be doing something wrong with it. When this happens it is not obvious what happened, and you are luck when you remember that you have been there.

Answered: how to convert deps,edn file to pom.xml file i am using leiningen

Mon, 09 Oct 2023 23:45:58 +0000

If you have the official Clojure CLI installed, you can run:

clojure -X:deps mvn-pom

to produce a pom.xml file.

If you're using Leiningen, don't you already have a project.clj file, and Leiningen will produce a pom.xml file from that.

Otherwise, perhaps you can provide more background on what your situation is - how your project is set up and what, exactly, you are trying to do?

Answered: Support of Maven Password Encryption in tools.deps

Mon, 25 Sep 2023 13:47:37 +0000

You are correct in that tools.deps does not currently support encrypted Maven passwords in the settings.xml. I have logged a jira for this at https://clojure.atlassian.net/browse/TDEPS-255.

Abstract env var reading in tools.deps

Sat, 16 Sep 2023 02:35:57 +0000

I have a Cursive user wanting to use the CLOJURE_CLI_ALLOW_HTTP_REPO env var. Since Cursive invokes tools.deps in-process, there's no way for me to set an env var in the current process. deps.clj has a nice abstraction for this - would it be possible to use this or something similar for tools.deps too? I assume this problem will affect any process using tools.deps as a library.

Answered: Can deps.edn tools opt-out of arguments parsing?

Tue, 18 Jul 2023 13:08:46 +0000

We don't plan to make any of the arg parsing optional - the -X and -T execution have a point of view, and tools not subscribing to this should use -M -m which gives you full control over arg parsing.

The clojure.run.exec ns is injected in the Clojure CLI (the code itself is in the brew-install repo). It's not easily available (somewhat intentionally) for external use as we have been evolving it over time and have not committed to a public api for that yet. I do expect that eventually it will be available, either in Clojure lib itself (which would make it analogous to clojure.main) or as a separate tiny lib.

Answered: should we not archive the clojure/tools.deps.alpha repository?

Sun, 16 Jul 2023 23:30:49 +0000

There may still be existing tools using it still. Is there any benefit to archiving other than as a usage signal?

Answered: Pop thread bindings correctly

Tue, 30 May 2023 14:34:25 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-249

Answered: Using deps/root with local/root

Thu, 04 May 2023 12:53:55 +0000

Yes, should implement this.

Logged as https://clojure.atlassian.net/browse/TDEPS-246

Answered: Specify an alias that is a set of other aliases?

Thu, 06 Apr 2023 05:10:34 +0000

This would be mighty useful for linting.

clj -M:eastwood:kibit:antq

could be

clj -M:lint

Answered: NullPointerException with tools.deps and find-versions

Thu, 30 Mar 2023 21:51:31 +0000

Yep, will fix. Logged as https://clojure.atlassian.net/browse/TDEPS-245

Tools deps perform sanity checking on deps.edn file

Thu, 23 Mar 2023 19:46:07 +0000

Peform validation of deps.edn files, providing useful error messages and information about misspelled keywords, invalid types, valid data in the wrong location.

Some motivating examples:

misspelled keywords:
:overide-deps
https://groups.google.com/g/clojure/c/g-Gy3Q7jHfk

including valid options in incorrect locations

:jvm-opts in the top level
https://app.slack.com/client/T03RZGPFR/C6QH853H8

invalid data types in valid edn files:

{:deps :org.clojure/tools.reader {:mvn/version "1.2.3"} org.clojure/tools.reader {mvn/version "1.2.3"}}

first dep has a keyword where a symbol should be present
second dep has a symbol where a keyword should be present

For implementation
spell-spec is a great tool to do this
https://github.com/bhauman/spell-spec

related JIRA ticket
https://clojure.atlassian.net/browse/TDEPS-238

Answered: How to fix error 'could not acquire write lock for 'artifact:org.bytedeco:opencv:4.5.5-1.5.7' ?

Tue, 14 Mar 2023 14:50:45 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-244

Answered: Can clojure.tools.deps.script.make-classpath2/run-core be considered a public API?

Wed, 22 Feb 2023 14:30:22 +0000

No, this class is not public API, and has regularly changed in breaking ways (and is about to do so again). I'm planning to move it out of tools.deps entirely and into the installer project as it's a facet of the CLI, not part of tools.deps.

Really, you should be going through clojure.tools.deps/create-basis for most functionality. I'm aware that there are some gaps between what's in make-classpath2/run-core and create-basis and I will shortly close that distance by enhancing some of the data returned in create-basis (in particular adding the basis config and merged argmap to provide access to jvm / main / exec info).

After that, the major differences between these will be: 1) supporting deprecated CLI stuff (some of which is going away now, some later) and 2) -T support, which really should be more directly supported in the deps api, but that's going to wait for a bit longer. Ultimately, make-classpath2 will use create-basis - that's where this is going.

Answered: Wondered if tools.deps might be missing a plexus-utils dependency given the Xpp3Dom import.

Sun, 22 Jan 2023 20:59:20 +0000

It has it via all the transitive maven deps. Is there an issue you're running into or anything?

Answered: Should :deps/prep-lib honor :exec-args in the build alias?

Tue, 11 Oct 2022 19:33:17 +0000

:deps/prep-lib does not use :exec-fn or :exec-args by design.

What is your use case for needing the arg map?

Answered: clj -X:deps tree ignores -Sdeps

Mon, 01 Aug 2022 10:47:40 +0000

Since version 0.12.1148 -X:deps tree takes basis settings:

$ clj -X:deps tree :extra '{:deps {ring/ring-core {:mvn/version "1.9.1"}}}'
org.clojure/clojure 1.11.1
  . org.clojure/spec.alpha 0.3.218
  . org.clojure/core.specs.alpha 0.2.62
ring/ring-core 1.9.1
  . ring/ring-codec 1.1.3
    . commons-codec/commons-codec 1.15
  . commons-io/commons-io 2.6
  . commons-fileupload/commons-fileupload 1.4
    X commons-io/commons-io 2.2 :older-version
  . crypto-random/crypto-random 1.2.0
    X commons-codec/commons-codec 1.6 :older-version
  . crypto-equality/crypto-equality 1.0.0

You can also pass e.g. list of aliases, which is quite useful:

$ clj -X:deps tree :aliases '[:dev :test]'

Answered: tools.deps integration with Sourcehut

Wed, 22 Jun 2022 15:26:48 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-228

Answered: tools.deps not working when downloading a big jar on a small machine

Fri, 29 Apr 2022 13:46:50 +0000

Thanks, logged as https://clojure.atlassian.net/browse/TDEPS-226

Answered: Possible concurrency issue with git deps

Thu, 24 Mar 2022 13:49:00 +0000

I'd like to see if it happens with the changes in 1.10.3.1058 as that could certainly affect this (changing to latest is fine, that's just the last change that I think matters here).

Answered: Non informative error message if git/sha of dependency in deps.edn cannot be found

Fri, 25 Feb 2022 14:32:03 +0000

Thanks, will be fixed for next release. The sha error was already fixed recently.

For missing url:

Error building classpath. :git/url not found or inferred for org.clojure/data.csv

For unknown sha:

Error building classpath. Commit not found for io.github.clojure/data.csv in repo https://github.com/clojure/data.csv.git at 1234567890123456789012345678901234567890

Answered: t.d.a does not support mvn versions starting with letters.

Thu, 17 Feb 2022 23:03:48 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-219

Answered: Support preparing :deps/:extra-deps in aliases

Sat, 12 Feb 2022 03:18:48 +0000

Added support for basis modifiers, including :aliases, in Clojure CLI prerelease 1.10.3.1082.

Answered: -X:deps might fail when user.clj requires something

Mon, 31 Jan 2022 14:22:13 +0000

Currently, the :deps alias does not do :replace-paths [], but it should and I've filed https://clojure.atlassian.net/browse/TDEPS-216 to fix that.

As a workaround, you can use -T:deps instead (this does :replace-paths ["."] so it's not exactly what you need, but will serve the purpose of removing the src dir from the classpath at least. Alternately, you could redefine the :deps alias.

Answered: :exclusions is underdocumented

Tue, 11 Jan 2022 14:12:56 +0000

Added in https://github.com/clojure/clojure-site/commit/beb2fc4204f4cb21a63290d86e38ddb00c48a2b3

Answered: Make :exclusions a common coordinate option?

Tue, 11 Jan 2022 13:47:10 +0000

It is supported on all coordinate types, just not well documented.

Answered: Resolve git deps via artifactory

Mon, 29 Nov 2021 17:57:12 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-214

Answered: Hope tools.deps.alpha add feature for listing available aliases

Mon, 29 Nov 2021 17:53:56 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-213

Answered: Using a git SHA for a local git dependency?

Fri, 05 Nov 2021 20:01:05 +0000

For this, you will just use a :git/url with file: protocol or no protocol. Admittedly, that does not currently work, but that is covered in https://ask.clojure.org/index.php/11251/allow-absolute-paths-for-file-based-git-urls.

Answered: :deps in dependency not (always) working when there is no :path specified in dependency

Tue, 26 Oct 2021 12:35:47 +0000

One thing that trips people up sometimes is that the Clojure CLI does not automatically pick up changes in local deps - you need to use clj -Sforce to force the local dep classpath to be refreshed. So if any of the above involved changing the deps.edn of your local deps, that's a necessary step. I would appreciate having the repro if you're using -Sforce and still seeing the issue.

Answered: deps.edn specs from tools.deps.alpha are out of date

Mon, 18 Oct 2021 17:38:37 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-210

Answered: Install clojure CLI via SDKMAN!

Wed, 08 Sep 2021 06:20:16 +0000

It seems there are two steps to achieving this

make archives available that meet sdkman's requirements
submit a PR to https://github.com/sdkman/sdkman-db-migrations (example PR: https://github.com/sdkman/sdkman-db-migrations/pull/521/files)

The archive should contain a single top-level directory like clojure-1.10.3.967, and inside there a bin directory with the executables.

Answered: s3 repo + certain deps appear to cause infinite resolution loop

Wed, 28 Jul 2021 21:48:52 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-199

I was able to reproduce this. There's some parallelism happening that can make the errors confusing, so using -Sthreads 1 helped a little there. I'm a little suspicious that this has more to do with sockets, and not with actual files. But, it needs more investigation.

Answered: Can :paths be symlinks that point outside the project?

Mon, 19 Jul 2021 14:18:45 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-194

Answered: git-resolve-tags doesn't support new format of git coords

Fri, 16 Jul 2021 14:03:44 +0000

Yep, thx for the report.

Unable to parse tools.deps -Sdescribe output as EDN on Windows

Tue, 08 Jun 2021 09:20:01 +0000

I installed tools.deps on Windows using Scoop and it works nicely. However, when I do clj -Sdescribe I get the following output:

$ clj -Sdescribe
    {:version "1.10.3.855"
     :config-files ["C:\Users\***\scoop\modules\ClojureTools\deps.edn" "C:\Users\***\.clojure\deps.edn" "deps.edn"]
     :config-user "C:\Users\***\.clojure\deps.edn"
     :config-project "deps.edn"
     :install-dir "C:\Users\***\scoop\modules\ClojureTools"
     :config-dir "C:\Users\***\.clojure"
     :cache-dir "C:\Users\***\.clojure\.cpcache"
     :force False
     :repro False
     :main-aliases ""
     :repl-aliases ""
     :exec-aliases ""}

and when I then try to parse this as EDN (which should be possible) via clojure.edn/read-string I get the error: Unsupported escape character: \U which obviously happens because the file path of C:\Users\... contains that.

This would probably need to be adjusted by the tools.deps team? I could work around it, but in a general case, I'd have no way of knowing if a \ signifies an escape character or a path separator. The output should probably be adjusted so a \ is escaped to \\.

Context: this fails for detecting tools.deps version as part of the integration into IntelliJ IDE with Cursive.

Could tools.deps.alpha support :jvm-opts via aliases-as-data, the same as :paths/:extra-paths?

Mon, 07 Jun 2021 18:37:03 +0000

At work, we have four or five JVM options that are common to almost every invocation of the CLI via aliases in our deps.edn file. Currently, we have :jvm-opts duplicated into each alias.

It would reduce duplication if we could just say :jvm-opts :common-opts in each alias and have a :common-opts alias that specified the JVM options in just one place or, even better, if the :jvm-opts vector could take a mix of keywords and strings and look up the keywords as aliases and merge that data in.

This would make :jvm-opts consistent with :paths and :extra-paths and help reduce duplication in deps.edn files.

In our specific case, we could then do the following:

;; under :aliases
:common-jvm-opts ["-Dclojure.core.async.go-checking=true"
                  "-Dclojure.tools.logging.factory=clojure.tools.logging.impl/log4j2-factory"
                  "-XX:-OmitStackTraceInFastThrow"
                  "--illegal-access=warn"]}

;; in a specific alias
:some-alias {
  :jvm-opts [:common-jvm-opts "-Dlogged-future=synchronous"]
}

Reflection warning when using tools.deps programatically

Sun, 06 Jun 2021 02:33:51 +0000

The following warning is a minor nuisance:

jar:file:/Users/vemv/.m2/repository/org/clojure/tools.deps.alpha/0.11.922/tools.deps.alpha-0.11.922.jar!/clojure/tools/deps/alpha/extensions/deps.clj:39:13: Reflection warning -  reference to field getCanonicalPath can't be resolved.

could it be fixed?

Thanks - V

Does tools.deps.alpha need a maven-core bump?

Thu, 20 May 2021 11:55:53 +0000

tools.deps.alpha 0.11.918 uses maven-core 3.6.3, which seems to be affected by CVE-2021-26291

Does this present a risk for users of tools.deps.alpha or the Clojure command-line tools? Would it make sense to bump the referenced version?

Could :replace-deps imply :replace-paths [] by default?

Tue, 15 Dec 2020 13:06:32 +0000

If an alias, or tool invocation using -Sdeps, discards a project's deps by using :replace-deps then there is a good chance that some or all of the project's namespaces become impossible to load due to their requirements now missing from the classpath.

If there are files in the project's default paths that are auto-loaded by clojure on startup, such as user.clj, the tool invocation might fail therefore. This can be mitigated by also specifying :replace-paths [], however this does not seem to be too well known (example 1, example 2, example 3).

I was wondering whether it is common for tools to replace a project's deps with their own but still use the project's paths? I believe in most cases the tool will be authored with no knowledge of the project it will be used in and should not expect to find anything useful to load from the project's own paths.

In order to make it easier to set up tool invocations, it would make sense to me to make :replace-deps imply :replace-paths [] unless otherwise specified, or something along these lines.

A repro case can be found at https://github.com/imrekoszo/depslink3_2#missing-replace-paths-repro-case

Migrated from https://ask.clojure.org/index.php/9857/could-option-that-variant-sdeps-avoid-having-specify-alias?show=9884#a9884

Edit: update opening paragraph to reference replace-deps as opposed to replace paths. I don't know why I wrote replace-paths there in the first place, this is about problems with replace-deps :)

Update: not happening, according to Alex: https://ask.clojure.org/index.php/11522/x-deps-might-fail-when-user-clj-requires-something?show=11526#c11526

Could the CLI add an option that is a variant of -Sdeps to avoid having to specify an alias?

Tue, 24 Nov 2020 19:21:52 +0000

Currently, there are several parts of deps.edn that only work under an alias. That means that if you want to do that via the command-line, you have to do:

clojure -Sdeps '{:aliases {:foo {...}}}' -(AMX):foo ...

(for example, :replace-deps for tooling)

It would be nice if you could just say:

clojure -Salias '{...}' -(AMX) ...

so you don't have to invent an alias, type that name twice, and wrap it in {:aliases ...}.

Logged as https://clojure.atlassian.net/browse/TDEPS-173

How can teams share common dependencies/tooling across multiple projects with deps.edn?

Mon, 23 Nov 2020 20:34:46 +0000

Here's my general problem statement (this applies to a monorepo as well):

a development team works together on multiple projects that each have their deps.edn file, and
those developers have their own preferred tooling configured in their own ~/.clojure/deps.edn file, and
the team as a whole wants a level of consistency in terms of certain library or tooling versions across multiple projects, by providing some standardized aliases and some "pinned" versions (e.g., :override-deps or :default-deps).

Bullets 1. and 2. are supported by the CLI/t.d.a. but there's nowhere to hang the multi-project standardization piece.

Currently, folks who want 3. are using CLJ_CONFIG to provide a team-standard deps.edn file but losing 1. in the process. This is considered a bit of a hack (although CLJ_CONFIG is documented).

Michiel Borkent notes that his clj-kondo tool faced a similar problem in terms of where it reads configuration data from and his solution was to provide a command-line argument that specified multiple configuration files to read. A similar approach could be taken with the Clojure CLI, allowing an arbitrary number of deps.edn files to be combined (after the system + user level ones and before the command-line -Sdeps data).

The current "system + user + project + command-line" logic is baked into tools.deps.alpha itself so this is not just a CLI script change -- and whatever approach is taken to address this needs to be available to tooling that needs to run analysis based on a combined deps.edn environment under user-specific aliases (as discussed here https://ask.clojure.org/index.php/9848/tooling-based-tools-alpha-construct-basis-specified-aliases).

How can tooling based on deps.edn/t.d.a construct a basis that is specified by aliases, without boilerplate code?

Mon, 23 Nov 2020 20:19:27 +0000

Discussion copied from Slack:

It is fairly common for tooling to be want to read the deps.edn environment as if it were under a set of aliases, i.e., for a tool to want to see the world as if a specific set of aliases were provided, that are different to the aliases needed to run the tool.

This touches on how -X.. mvn-pom works, as well as other tools on https://github.com/clojure/tools.deps.alpha/wiki/Tools such as depot: the environment needed to run the tool is not the same as the environment the tool wants for analysis.

depstar "works around" this problem by relying on its own runtime environment being the same as what goes into the JAR file but just excluding itself. This is only tenable because it is a very small tool that has zero external dependencies. You can override this and tell depstar to use a different classpath, but that approach doesn't work for tools that actually want to look at the versions of dependencies, such as mvn-pom, depot, etc.

Alex Miller said: "the datomic ion dev tools is another example"

Michiel Borkent said: "I also have a couple of tools that just receive a --classpath arg. But it depends on the tool. For mvn-pom that might not be so convenient, and getting a list of aliases to resolve versions with might be better."

Clarification of the "ask" here, and an addition courtesy of Alex: this process must take into account the various deps.edn files that the CLI already uses -- system, user, project, command-line -- and must respect the equivalent of -Srepro so that the user deps.edn can be elided if desired. In addition, if t.d.a is enhanced to support multiple "project" deps.edn files, per https://ask.clojure.org/index.php/9849/teams-common-dependencies-tooling-across-multiple-projects, then this process should also support that.

What tools need is something in t.d.a that they can call with:

A list of aliases
An option equivalent to -Srepro
The implicit list of deps.edn files that match how the CLI would read them (this is intended to be weasel-wording to allow for the "extra deps.edn file" posited in that other "ask" to be specified here somehow

The idea here is that tooling wants to mimic how the Clojure CLI processes deps.edn files and aliases and certain other options but the current API exposed by t.d.a is too low-level to make this easy and we don't want every tool based on t.d.a to have to duplicate all that multi-file merging and alias selection.