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

Question

When adding a dependency, I'd like to be able to specify aliases in coordinates of libraries that use deps.edn, for example:

{:deps {org.clojure/clojure {:mvn/version "1.10.0"}
        org.openjfx/javafx-base {:mvn/version "12-ea+10"}}
 :aliases {:web {:extra-deps {org.openjfx/javafx-web {:mvn/version "12-ea+10"}}
                 :extra-paths ["src/web"]}
           :controls {:extra-deps {org.openjfx/javafx-controls {:mvn/version "12-ea+10"}}
                      :extra-paths ["src/controls"]}}
 :paths ["src/base"]}

use:

{:deps {git/lib {:git/url "..." 
                 :sha "..."
                 :aliases ["controls"]}}}

This way it will be possible to make more fine-grained libraries that may have optional code/dependencies which won't bloat classpath when unneeded.

Answer 1

Comment made by: borkdude

Interestingly, I think this also implements a feature that some people have been asking for, namely managed dependencies.

libs/deps.edn could be an empty project that only describes groups of dependencies via aliases (managed deps).
app/deps.edn can consume these groups like in the above example.

Minor detail: maybe :aliases should contain keywords instead of strings?

Answer 2

Reference: https://clojure.atlassian.net/browse/TDEPS-116 (reported by alex+import)

Answer 3

Yes please! Being able to use an alias, or aliases, in a git dependency offers the opportunity to stitch together different facets of a single project. A single project may contain aliases for different architectural levels such as a core library, or a server implementation etc. Clients of that project could then choose to use those different facets as required. The current alternative is to use multiple git repositories.

Answer 4

We have a specific use-case for this at Metabase and it's one of the things that's making it hard for us to transition to deps.edn. Here's a simplified version of the problem we're facing:

At Metabase we ship both an FOSS edition (under the AGPL) and an Enterprise Edition under a commercial license. We can't ship the Oracle JDBC driver in the FOSS edition because the license terms of the JDBC driver make it AGPL-incompatible. However, we can ship it with the EE version.

The Oracle driver is itself a subproject in the larger Metabase-core repo.
We want to be able to have a top-level :ee alias that merges in the :ee aliases from the :local/root stuff it pulls in. Example:

;; ./deps.edn
{:deps
 {:local/root "oracle-driver"}
 :aliases 
 {:ee
  {:extra-deps {:local/root "oracle-driver", :alias :ee}}}}

;; oracle-driver/deps.edn
{:aliases
 {:ee
  {:extra-deps
   {com.oracle.ojdbc/ojdbc8 {:mvn/version "19.3.0.0"}}}}}

Comments

+1 this feature would exactly solve a problem I have too

Answer 5

One more use case that I think this could solve:

We have a monorepo structure that includes various libraries in sub-folders, each with their own deps.edn.

1. /deps.edn - defines :deps {is.mad/server-web3 {:local/root "./server/web3"}}
2. /server/web3/deps.edn - defines :test alias with {:extra-paths ["test"]}
3. /server/web3/src/<more files>
4. /server/web3/test/<more files> - these I would like to be included in the build & run

Currently the aliases defined in the sub-projects' (individual libraries) deps.edn aren't taken into consideration. If they were, it would allow us to define :test alias for each project that has :extra-paths with its test folder. (though the relative path of the test folder in the project would have to be resolved starting from the deps.edn that defines it).

That way would be possible to run tests for one or more sub-projects from the top level.
E.g. clj -A:shadow:test watch test-node

Currently to achieve it there are 2 options that introduce duplication or other unwanted side-effects
1. Define aliases in the top-level deps.edn for each sub-project so that each alias has extra-deps and extra-paths
2. Have each sub-project include the test folder in paths in its deps.edn
- side effect of this is that the tests can have dependencies that shouldn't go into the build

Relevant thread in Clojurians Slack https://clojurians.slack.com/archives/C03S1KBA2/p1662484004746779

Comments

Just as an FYI, this is something Polylith addresses (for Clojure) when running tests.