clj -X:deps tree ignores -Sdeps

Question

As the title says, clj -X:deps tree ignores the -Sdeps option:

$ clj -Sdeps '{:deps {ring/ring-core {:mvn/version "1.9.1"}}}' -X:deps tree
org.clojure/clojure 1.10.2
  . org.clojure/spec.alpha 0.2.194
  . org.clojure/core.specs.alpha 0.2.56

In contrast to clj -Stree:

$ clj -Sdeps '{:deps {ring/ring-core {:mvn/version "1.9.1"}}}' -Stree
org.clojure/clojure 1.10.2
  . org.clojure/spec.alpha 0.2.194
  . org.clojure/core.specs.alpha 0.2.56
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

Is this behavior intended? If so, why?

I believe it's intentional since I found this behavior comes from this seemingly purposeful change, but I still don’t get the reason for that.

BTW I know there is a workaround like the following if I want to use clj -X:deps tree anyway:

$ clj -Sdeps ... -Strace
$ clj -X:deps tree :file '"trace.edn"'

Answer 1

Yes, this behavior is intended. When running as a -X:deps program, you are running a tool and any classpath options you use on the command line apply to the program, not to the tree being computed by the program.

We are still talking about how to convey classpath modifying options to the -X:deps program itself, possibly with some standard set of options/and or lib support for programs that calculate a classpath basis.

Comments

Thank you for answering! That makes much sense.

> When running as a -X:deps program, you are running a tool and any classpath options you use on the command line apply to the program, not to the tree being computed by the program.

So, that means third-party -X:deps programs (like a library) in general should not rely on the runtime basis?

---

-X programs get an injected runtime basis for the tool invocation. That basis will be based on the classpath you specify for the tool via your aliases. If using :replace-deps the project basis will not be included (or modifiable) via clj options. If using :extra-deps (for example, a test runner that augments your project classpath rather than replaces it), then that basis may be useful to manipulate. So ... it depends.

---

Ah, I got you (I noticed I mixed up "-X:deps programs" and "-X programs" a bit). Thanks for elaborating!

Answer 2

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 3

This feels in keeping with several other decisions as well as several stated design goals of t.d.a.

I recently went through a (big) change with depstar in this area: in the 1.0 stream it used the runtime/injected basis and certain things were easy but certain things were impossible; in the 2.0 stream it uses the project basis and now everything is possible but certain previously easy things are now a bit harder.

To me, this is a very clear decomplection.

(btw, I edited the title and description to use -X:deps, not -Xdeps, which is the correct form)