Clojure Q&A - Recent activity in tools.deps

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

Fri, 03 Apr 2026 09:52:20 +0000

GitHub agents are a good spot to see the problem, as they start with an "empty" .m2 folder.
If here:
https://github.com/scicloj/metamorph.ml/blob/14b4e609a18ec9b291bc26a160108d249e56ba70/.github/workflows/main.yml#L50

I would remove here the "-Sthreads 1", the build would (I believe) fail on each run.

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

Wed, 24 Dec 2025 22:42:34 +0000

Yeah, I tried to create a build.clj that would do this from the basis, but I also got nil :paths for those non-jar files

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

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

Fri, 17 Jan 2025 14:53:03 +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.

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

Thu, 03 Oct 2024 21:23:07 +0000

Agreed. Polylith is hamstrung on github to deliver granular libraries without this feature available.

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

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

Fri, 09 Aug 2024 03:12:29 +0000

Mark, you mean have :main-opts that contains a "-e" and an expression that programmatical calls each of the three -main functions? Like "(do (eastwood/-main) (kibit/-main) (antq/-main))"
(whatever the main namespaces are).

Given that a lot of tools call (shutdown-agents) at the end, you likely won't be able to run -main functions after that...

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

Thu, 16 May 2024 10:19:29 +0000

I see.
Thanks for the update, Alex.

In case you have any ideas/pointers/thoughts/notes on how to approach this that may help others with much less knowledge of the cli codebase tackle the problem, please feel free to add them to the bug entry.

https://clojure.atlassian.net/browse/TDEPS-8

Thanks again,
Leandro

Commented: Install clojure CLI via SDKMAN!

Wed, 01 May 2024 02:38:53 +0000

A bit old, and a pandemic after, but any chance to get this in ?

Commented: Transitive dependency resolution skipping some libs

Wed, 28 Feb 2024 14:22:35 +0000

Thank you for the reference, Alex. It helped me to pinpoint what was causing my issues.
(the redaction was to simplify because most of the libs were internal to my company, so exposing their names or not would be the same, as they are not publicly available)

My issue was caused by an `:exclusion` on the third dependency level:
my-bundle -> my-component -> my-lib
and "my-lib" contain this below in the "deps.edn":
     amazonica/amazonica                   {:mvn/version "0.3.165" :exclusions [com.taoensso/nippy]}
     com.taoensso/faraday                  {:mvn/version "1.12.0" :exclusions [com.taoensso/nippy]}
     com.taoensso/nippy                    ^:antq/exclude {:mvn/version "3.1.1"}

Removing the `:exclusions`, as a version of nippy was being set at the same level, made the weird behavior with other libs disappear (although now Cursive in IntelliJ shows two nippy versions, 3.1.1 and 3.2.0, but deps' tree does not).

The inconsistent behavior was happening with the libs `tick/tick [0.7.5]` and `com.stuartsierra/dependency [1.0.0]` (from `com.stuartsierra/components [1.1.0]`) not being included in the classpath

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

Thu, 15 Feb 2024 00:50:23 +0000

There weren't much updates for the last few years. Anything we can do to help move this forward?

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

Wed, 07 Feb 2024 10:26:24 +0000

We also had this problem in the past. What we've been doing for years now is to have a "run-as-user.sh" script with the following content:

```
#!/usr/bin/env bash

set -eu

NEW_UID=$(stat -c '%u' /app)
NEW_GID=$(stat -c '%g' /app)

groupmod -g "$NEW_GID" -o hop >/dev/null 2>&1
usermod -u "$NEW_UID" -o hop >/dev/null 2>&1

exec chpst -u hop:hop -U hop:hop env HOME="/home/hop" "$@"
```

that we use as the entry point for the container. Then in the Docker file for the container we also add the following lines (in additon to whatever is needed for that container), and the command required to install the `runit` package (which is the one that provides the `chpst` command) in the distribution used by your Docker image:

```
RUN useradd --home-dir /home/hop --create-home --shell /bin/bash --user-group hop
COPY run-as-user.sh /usr/local/bin
WORKDIR /app
ENTRYPOINT ["run-as-user.sh"]
```

And when running the container, we mount whatever directories are needed (~/.m2, the Clojure app directory, etc) using volumes inside the container. We mount the Clojure application directory under `/app` inside the container (which is where the `run-as-user.sh` script will look). Then the `run-as-user.sh` script takes care of changing the UID and GID of the account used inside the container, to match those of the user owning the `/app` directory (which is the outside user).

Hope that helps.

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?

Commented: Support of Maven Password Encryption in tools.deps

Mon, 25 Sep 2023 14:23:03 +0000

I've sent you an invite to join jira so you can contribute on the jira. Even more so than the patch, would welcome a discussion on approach first. Not sure if there are Maven APIs you can use for this or if it would require xml parsing etc.

And there are definitely many possible ways to convey the master Maven password for decryption so would like to see a discussion of tradeoffs for that.

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.

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

Tue, 18 Jul 2023 18:02:46 +0000

Unfortunate for me, but probably a good thing to present a consistent API of sorts for users.

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

Sun, 16 Jul 2023 23:47:36 +0000

> There may still be existing tools using it still.

even archived it is possible to clone via git (install)

> Is there any benefit to archiving other than as a usage signal?

make it explicit that the repository is no longer maintained

Closed: Pop thread bindings correctly

Wed, 31 May 2023 21:06:22 +0000

expand-deps dynamically binds
clojure.tools.deps.alpha.util.dir/the-dir before submitting worker
threads. While hard to reproduce, this empirically breaks the
canonicalization of file paths from :local/root dependencies.

Per the Clojure docs for push-thread-bindings:

WARNING: This is a low-level function. Prefer high-level macros like
binding where ever possible. [...] Each call MUST be
accompanied by a matching call to pop-thread-bindings wrapped in a
try-finally!

bound-fn* ensures that dynamically are properly pushed and popped. Using
it from submit-task removes the :local/root canonicalization issues.

 .../clojure/clojure/tools/deps/alpha/util/concurrent.clj    | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/main/clojure/clojure/tools/deps/alpha/util/concurrent.clj b/src/main/clojure/clojure/tools/deps/alpha/util/concurrent.clj
index b1508c10..814e0190 100644
--- a/src/main/clojure/clojure/tools/deps/alpha/util/concurrent.clj
+++ b/src/main/clojure/clojure/tools/deps/alpha/util/concurrent.clj
@@ -29,11 +29,7 @@
 
 (defn submit-task
   ^Future [^ExecutorService executor f]
-  (let [bindings (get-thread-bindings)
-        task #(do
-                (push-thread-bindings bindings)
-                (f))]
-    (.submit executor ^Callable task)))
+  (.submit executor ^Callable (bound-fn* f)))
 
 (defn shutdown-on-error
   [^ExecutorService executor]

Answer selected: Using deps/root with local/root

Thu, 04 May 2023 16:40:39 +0000

Yes, should implement this.

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

Closed: NullPointerException with tools.deps and find-versions

Fri, 31 Mar 2023 15:07:27 +0000

When I want to find available versions for e.g. ragtime, I'd run this:

clj -X:deps find-versions :lib ragtime/ragtime
;; the output
{:mvn/version "0.6.2"}
{:mvn/version "0.6.3"}
{:mvn/version "0.6.4"}
{:mvn/version "0.7.0"}
{:mvn/version "0.7.1"}
{:mvn/version "0.7.2"}
{:mvn/version "0.8.0"}
{:mvn/version "0.8.1"}

However, when groupid is omitted, tools.deps will throw a NullPointerException. Example command:

clj -X:deps find-versions :lib ragtime
Execution error (NullPointerException) at java.util.regex.Matcher/getTextLength (Matcher.java:1283).
null

And the stacktrace:

{:clojure.main/message
 "Execution error (NullPointerException) at java.util.regex.Matcher/getTextLength (Matcher.java:1283).\nnull\n",
 :clojure.main/triage
 {:clojure.error/class java.lang.NullPointerException,
  :clojure.error/line 1283,
  :clojure.error/symbol java.util.regex.Matcher/getTextLength,
  :clojure.error/source "Matcher.java",
  :clojure.error/phase :execution},
 :clojure.main/trace
 {:via
  [{:type java.lang.NullPointerException,
    :at [java.util.regex.Matcher getTextLength "Matcher.java" 1283]}],
  :trace
  [[java.util.regex.Matcher getTextLength "Matcher.java" 1283]
   [java.util.regex.Matcher reset "Matcher.java" 309]
   [java.util.regex.Matcher <init> "Matcher.java" 229]
   [java.util.regex.Pattern matcher "Pattern.java" 1093]
   [clojure.core$re_matcher invokeStatic "core.clj" 4881]
   [clojure.core$re_matches invokeStatic "core.clj" 4911]
   [clojure.core$re_matches invoke "core.clj" 4911]
   [clojure.tools.deps.extensions.git$auto_git_url$fn__1454
    invoke
    "git.clj"
    31]
   [clojure.core$some invokeStatic "core.clj" 2718]
   [clojure.core$some invoke "core.clj" 2709]
   [clojure.tools.deps.extensions.git$auto_git_url
    invokeStatic
    "git.clj"
    30]
   [clojure.tools.deps.extensions.git$auto_git_url invoke "git.clj" 23]
   [clojure.tools.deps.extensions.git$eval1534$fn__1535
    invoke
    "git.clj"
    152]
   [clojure.lang.MultiFn invoke "MultiFn.java" 244]
   [clojure.tools.deps.extensions$find_all_versions$fn__446
    invoke
    "extensions.clj"
    149]
   [clojure.core$some invokeStatic "core.clj" 2718]
   [clojure.core$some invoke "core.clj" 2709]
   [clojure.tools.deps.extensions$find_all_versions
    invokeStatic
    "extensions.clj"
    149]
   [clojure.tools.deps.extensions$find_all_versions
    invoke
    "extensions.clj"
    145]
   [clojure.tools.deps.cli.api$find_versions
    invokeStatic
    "api.clj"
    399]
   [clojure.tools.deps.cli.api$find_versions invoke "api.clj" 379]
   [clojure.lang.Var invoke "Var.java" 384]
   [clojure.run.exec$exec invokeStatic "exec.clj" 89]
   [clojure.run.exec$exec invoke "exec.clj" 78]
   [clojure.run.exec$_main$fn__219 invoke "exec.clj" 216]
   [clojure.run.exec$_main invokeStatic "exec.clj" 212]
   [clojure.run.exec$_main doInvoke "exec.clj" 180]
   [clojure.lang.RestFn applyTo "RestFn.java" 137]
   [clojure.lang.Var applyTo "Var.java" 705]
   [clojure.core$apply invokeStatic "core.clj" 667]
   [clojure.main$main_opt invokeStatic "main.clj" 514]
   [clojure.main$main_opt invoke "main.clj" 510]
   [clojure.main$main invokeStatic "main.clj" 664]
   [clojure.main$main doInvoke "main.clj" 616]
   [clojure.lang.RestFn applyTo "RestFn.java" 137]
   [clojure.lang.Var applyTo "Var.java" 705]
   [clojure.main main "main.java" 40]]}}

Cli version: "1.11.1.1262".

Best,
Sanel

Recategorized: Tools deps perform sanity checking on deps.edn file

Thu, 23 Mar 2023 20:10:41 +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

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

Wed, 22 Feb 2023 20:32:37 +0000

I don't know if this is the best bandwidth way to have this conversation, if it would help to have a convo, you know where to find me, and I'm happy to make out of that a public writeup. This is not secret knowledge but it is context dependent and I'm not totally sure what the set of things is you need to do.

Also, I have some changes in work right now that affect the answers a bit, particularly around the exec argmap attributes.

Answer selected: Resolve git deps via artifactory

Mon, 26 Dec 2022 12:30:54 +0000

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

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

Mon, 24 Oct 2022 01:29:48 +0000

It appears that an :exec-args attribute in a :deps/prep-lib's :alias is not honored, i.e. it's not possible to declare default args for the prep :fn.

Given the following statement in the Deps and CLI Reference on :deps/prep-lib:

Those libs will run the command specified there by alias and function, as if: clj -T:<alias> <fn>.

And this one on -T:

The function is invoked with a map in the same way as -X execution, built from :exec-args if found in aliases and key/vals provided on the command line.

It seems like this should be possible. Is this a bug in the implementation, in the documentation or in my understanding? :-)

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

Mon, 24 Oct 2022 01:25:37 +0000

When I try to download all version of com.google.javascript/closure-compiler-unshaded t.d.a returns nil, digging in the problem I saw that this line is being responsible to the problem since it’s only matching versions starting with number and all the versions of com.google.javascript/closure-compiler-unshaded starts with a letter v.
Is it supposed to work like that or is it a bug?

The executed command was the following.

clj -X:deps find-versions :lib com.google.javascript/closure-compiler-unshaded

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

Thu, 08 Sep 2022 14:13:17 +0000

Originally asked at https://clojurians.slack.com/archives/C6QH853H8/p1643624068729959

It appears -X:deps gets tricked by a user.clj on the path that requires a namespace that is on the project classpath but not on the classpath that -X:deps itself uses.

Is this expected? Is there any better way to handle this than adding something like -Sdeps '{:aliases {:no-paths {:replace-paths []}}}' -A:no-paths?

Repro:

; # enviroment
;
; clojure -Srepro -version
Clojure CLI version 1.10.3.1069
;
; # deps & source
;
; echo '{:paths ["src"] :deps{org.clojure/java.classpath {:mvn/version "1.0.0"}}}' > deps.edn
; mkdir src && echo '(ns user (:require clojure.java.classpath))' > src/user.clj
;
; # launch repl
;
; clj -Srepro
Clojure 1.10.3
user=> (find-ns 'clojure.java.classpath)
#object[clojure.lang.Namespace 0x21325036 "clojure.java.classpath"]
user=>

; # check deps
;
; clojure -Sforce -Srepro -X:deps list :license :none
Exception in thread "main" Syntax error compiling at (user.clj:1:1).
	at clojure.lang.Compiler.load(Compiler.java:7652)
	at clojure.lang.RT.loadResourceScript(RT.java:381)
	at clojure.lang.RT.loadResourceScript(RT.java:368)
	at clojure.lang.RT.maybeLoadResourceScript(RT.java:364)
	at clojure.lang.RT.doInit(RT.java:486)
	at clojure.lang.RT.init(RT.java:467)
	at clojure.main.main(main.java:38)
Caused by: java.io.FileNotFoundException: Could not locate clojure/java/classpath__init.class, clojure/java/classpath.clj or clojure/java/classpath.cljc on classpath.
	at clojure.lang.RT.load(RT.java:462)
	at clojure.lang.RT.load(RT.java:424)
	at clojure.core$load$fn__6856.invoke(core.clj:6115)
	at clojure.core$load.invokeStatic(core.clj:6114)
	at clojure.core$load.doInvoke(core.clj:6098)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invokeStatic(core.clj:5897)
	at clojure.core$load_one.invoke(core.clj:5892)
	at clojure.core$load_lib$fn__6796.invoke(core.clj:5937)
	at clojure.core$load_lib.invokeStatic(core.clj:5936)
	at clojure.core$load_lib.doInvoke(core.clj:5917)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$load_libs.invokeStatic(core.clj:5974)
	at clojure.core$load_libs.doInvoke(core.clj:5958)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$require.invokeStatic(core.clj:5996)
	at clojure.core$require.doInvoke(core.clj:5996)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at user$eval138$loading__6737__auto____139.invoke(user.clj:1)
	at user$eval138.invokeStatic(user.clj:1)
	at user$eval138.invoke(user.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:7181)
	at clojure.lang.Compiler.eval(Compiler.java:7170)
	at clojure.lang.Compiler.load(Compiler.java:7640)
	... 6 more
;
; # check deps with workaround
;
; clojure -Sdeps '{:aliases {:no-paths {:replace-paths []}}}' -A:no-paths -Sforce -Srepro -X:deps list :license :none
org.clojure/clojure 1.10.3
org.clojure/core.specs.alpha 0.2.56
org.clojure/java.classpath 1.0.0
org.clojure/spec.alpha 0.2.194

Edit: JIRA fixed

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]'

Answer selected: tools.deps integration with Sourcehut

Wed, 22 Jun 2022 15:29:25 +0000

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

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

Thu, 16 Jun 2022 01:28:23 +0000

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

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

Thu, 09 Jun 2022 20:18:26 +0000

I started an ec2 t3.nano instance and created a clojure deps project. The only dependency I had was a private jar file which weighted around ~100mb.
clj command could not download the file and was misleading in its error :
Error building classpath. Could not find artifact name/of/artifact

By curiosity I looked at tools.deps code and tried to run the s3 call :
`
(aws/invoke s3-client {:op :GetObject

                     :request {:Bucket "bucketname"
                               :Key "/path/to/jar"}})

and then we had a clear error (see https://clojurians.slack.com/files/U2N9GDB1U/F03E16TB10Q/image.png)

It looks like cognitect http is keeping the file in memory, on a really small instance or a container it does not work (it worked with mvn)
Quick fix: have a better error message
Thanks a lot

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

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

Thu, 03 Mar 2022 20:06:11 +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: 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.

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

Mon, 31 Jan 2022 16:43:19 +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

Answer selected: Make :exclusions a common coordinate option?

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

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

Answer selected: :exclusions is underdocumented

Tue, 11 Jan 2022 14:24:48 +0000

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

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.

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

Tue, 26 Oct 2021 14:16:58 +0000

Thanks! I can't reproduce it when having forced the classpath refresh.

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

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

The specs for deps.edn files in the tools.deps.alpha repo are fairly out of date now, and don't coincide with what the documentation claims.

Discrepancies I have noticed:

New git syntax is not supported, :git/sha, :git/tag and the like.
Specs for coords claim that Maven and local coords can include a :path field.
No mention of :deps/root or :deps/manifest in coords.
None of the recent tools stuff is present.
Missing top-level entries: :mvn/repos, :mvn/local-repo, :tools/usage, :deps/prep-lib.

Having accurate specs is really useful for tool development, since I can then use them to generate deps files to test e.g. Cursive against, as well as ensuring that any parsing I do is correct. It would be great if these could be brought up to date.

Comment edited: Add support for Google Artifact Registry in tools.deps and clj

Mon, 13 Sep 2021 14:13:49 +0000

Is there anyway to vote for this on Jira, or should I just vote for it here?

We are using Datomic Cloud so using Leiningen is not an option, but we also have to pull in some private artifacts from Artifact Registry.

Edit: we do have access to git repo for the libs, so that should be a workable solution for us right now

Comment edited: Allow user to specify the path to Maven settings (or provide repo credentials directly)

Tue, 07 Sep 2021 15:27:05 +0000

*REMOVED COMMENT*

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

Thu, 29 Jul 2021 03:44:43 +0000

Yep, thx for the report.

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

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