Welcome! Please see the About page for a little more info on how this works.

+5 votes
in tools.deps by
retagged by

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

3 Answers

+2 votes

This seems like an answer, not a problem - what's the scenario where you want to do this?

Certainly one specific scenario I'm aware of is wanting to run a tool that doesn't use the project deps, something like:

clojure -Sdeps '{:aliases {:a-tool {:replace-deps {my/tool {:mvn/version "..."}} :main-opts ["..."]}}}' -M:a-tool

or equivalent with :exec-fn/:exec-args/-X instead.

Are there other use cases that are not about tools?

I think this usecase is specific to tools, given the intent is that you run something that completely ignores any project `deps.edn`s if there are any.
0 votes

Another use case might be running a repl and adding a set of repl-specific deps just for this execution...

clojure -Sdeps '{:aliases {:dev {:extra-deps { ... }}}' -A:dev
In this case you could just use -Sdeps '{:deps { ... }}' right?

Running a REPL with extra paths would be a use case (because :paths overrides the project paths so you need :extra-paths which has to be in an alias).

This would be purely a convenience, to allow for less typing, for a case that folks seem to have grumbled about, on and off, since the Clojure CLI appeared.

And, yes, it's mostly about running ad hoc tooling in a project where you don't want to add it to either the project deps.edn or your user deps.edn.
True, I guess you would just get the deps merged in in that case.
0 votes
edited by

So far I ran into 2 caveats with the current, alias-based approach:

  1. If the project deps.edn is invalid, the tool will fail, regardless of whether the tool would want to use it or not
  2. :replace-deps is insufficient to try and ignore the effects of the projects deps.edn
    • paths set by the project deps.edn might still affect the tool operation. like a user.clj under the commonly-used src folder, or a data_readers.clj
    • this can currently be mitigated by specifying :replace-paths [] but like the unnecessary alias, this is also kind of a chore
    • :mvn/repos might also be considered and could have an effect

Edit: repro case for point 2:

In the following repo: https://github.com/imrekoszo/depslink3_2#missing-replace-paths-repro-case

No replace-paths:

> clojure -Srepro -Sdeps '{:aliases {:blank {:replace-deps {}}}}' -M:blank

Exception in thread "main" Syntax error compiling at (user.clj:1:1).
at clojure.lang.Compiler.load(Compiler.java:7648)
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 net/cgrand/xforms__init.class, net/cgrand/xforms.clj or net/cgrand/xforms.cljc on classpath.
at clojure.lang.RT.load(RT.java:462)...


> clojure -Srepro -Sdeps '{:aliases {:blank {:replace-deps {} :replace-paths []}}}' -M:blank

Clojure 1.10.1
Point 2 is very useful -- I hadn't thought of the possibility of a project's paths messing with tooling!

However, it's orthogonal to my question: even if the "convenience feature" was added to short-circuit the need to specify :aliases/:foo and -M:foo, you'd still need to remember to specific both :replace-deps _and_ :replace-paths -- in other words, you'd still potentially need an addition "convenience feature" to say "use just these deps and no paths" and I'm not sure that the need to override the paths would be common enough to make that worthwhile?
edited by
I see your point, Sean. I'm probably using this website incorrectly :) In any case, I am just trying to raise awareness of these so it can be considered before a tools-oriented update is released.

I think I'd reverse your ending question though - is it 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.

It would make sense to me to make `:replace-deps` imply `:replace-paths []` unless otherwise specified or something along these lines. I'll open a separate question about this as it does indeed seem orthogonal.

Edit: asked at https://ask.clojure.org/index.php/9947/could-replace-deps-imply-replace-paths-by-default