This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-05
Channels
- # announcements (1)
- # aws (6)
- # babashka (8)
- # beginners (22)
- # cider (12)
- # clj-kondo (1)
- # cljdoc (15)
- # clojure (109)
- # clojure-dev (6)
- # clojure-europe (40)
- # clojure-losangeles (5)
- # clojure-uk (1)
- # clojurescript (28)
- # data-oriented-programming (3)
- # datahike (9)
- # datalevin (9)
- # holy-lambda (2)
- # juxt (5)
- # lsp (4)
- # malli (2)
- # meander (1)
- # missionary (5)
- # nextjournal (3)
- # off-topic (17)
- # reagent (1)
- # reitit (8)
- # releases (1)
- # sci (16)
- # shadow-cljs (7)
- # sql (9)
- # tools-deps (9)
- # transit (1)
What's the thinking on having one alias "depend" on another; for example, in our libs, we tend to have a :dev alias that defines test namespaces and dependencies, and then a :test alias that brings in the test-runner dependency and exec-fn; we end up having to execute clj -X:dev:test
. What would be the repercussions of something like {:depends-on [:dev]}
to incorporate aliases. I have to imagine this is something you've already considered.
My own thoughts are about the complexity this will bring, especially if one alias depends one another which then depends on another… At present aliases are defined without dependencies on other aliases, so I consider them akin to pure functions. The results of composing aliases, :dev:test, it therefore simple to understand Adding dependencies between aliases feel like it will easily break this simple model and make aliases more complex. I am sure we appreciate the circular dependencies challenges that arise from library dependencies when each library includes a range of other libraries. I assume alias dependencies would also increase the complexity of the tooling that needs to processes those alias dependencies. I therefore value keeping aliases simple and self-defined
@hlship I think that's probably one of the most requested features in one form or another... There's at least one Q on http://ask.clojure.org about (which may have a JIRA link).
Here's one of them https://ask.clojure.org/index.php/9302/allow-transitive-deps-edn-dependencies-to-inherit-aliases
This is another related Q https://ask.clojure.org/index.php/7843/allow-specifying-aliases-coordinates-that-point-projects
And this one is also related https://ask.clojure.org/index.php/10564/specify-an-alias-that-is-a-set-of-other-aliases
The latter would allow you to have a :test
alias that expanded to :dev:runner
for example.
(the first two are more about aliases in projects you depend on -- your :depends-on
threw me for a second there, until I re-read it and posted that third link!)
My own thoughts are about the complexity this will bring, especially if one alias depends one another which then depends on another… At present aliases are defined without dependencies on other aliases, so I consider them akin to pure functions. The results of composing aliases, :dev:test, it therefore simple to understand Adding dependencies between aliases feel like it will easily break this simple model and make aliases more complex. I am sure we appreciate the circular dependencies challenges that arise from library dependencies when each library includes a range of other libraries. I assume alias dependencies would also increase the complexity of the tooling that needs to processes those alias dependencies. I therefore value keeping aliases simple and self-defined
Taking my user level aliases as an example, I create many aliases with a specific purpose which can mostly be used by themselves. This makes the Clojure command simple and more deterministic https://github.com/practicalli/clojure-deps-edn