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

Question

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.

Answer 1

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

Comments

Nice! Thank you!

Answer 2

You can use tools.deps as a library:

(require '[clojure.tools.deps.alpha :as deps]
         '[clojure.java.io :as io])

(let [aliases [:repl :dev]
      deps (deps/slurp-deps (io/file "deps.edn"))]
  (-> deps
      (deps/calc-basis
        {:resolve-args (deps/combine-aliases deps aliases)
         :classpath-args (deps/combine-aliases deps aliases)})
      :classpath
      keys))
; => ...classpath for given aliases

It would be better for the tool ecosystem if mvn-pom and other build tools accepted a basis instead of a list of aliases, and conversion of aliases+deps.edn to a basis was done in a single place at the edge of a tool.

Comments

That's not an answer to this question (and I already know how to use tools.deps.alpha).

Answer 3

I suppose it is only somewhat related to the "list of deps.edn files" part of this, that while currently there is a way to ignore the user deps.edn by using -Srepro, there isn't a similar way to ignore any local (project) deps.edn that might be in the current working directory. For some tool invocations it could be useful to have such a mechanic available.

Edit: this has been recorded as https://ask.clojure.org/index.php/9857/could-option-that-variant-sdeps-avoid-having-specify-alias (thanks Sean)

Comments

That's the intention behind :replace-deps and :replace-paths per https://clojure.org/reference/deps_and_cli#_replace_project_environment_tool -- you declare a tool's alias in either your user-level deps.edn or on the command-line and it will use exactly those deps/paths (it's not quite what you're suggesting but should mostly address that use case).

---

Yep, and that works. However: a) you need an alias and can't just -Sdeps without setting the alias up b) a local deps.edn would still be read in so any syntax (and potentially other) errors in that file would make the tool fail to run, even if the tool has nothing to do with that local deps.edn.

---

Both true, and I've often felt annoyed by having to specify an alias in -Sdeps just to get around that restriction. It would be nice if there was a variant of -Sdeps that behaved "as-if" it were just the portion under some alias and that alias was automatically selected by tooling.

---

Asked at https://ask.clojure.org/index.php/9857/could-option-that-variant-sdeps-avoid-having-specify-alias