Fork me on GitHub

I agree that the -A execution option does not work consistently (has side effects) as described in the documentation. It's also unclear about its future. If it's deprecated, typically that means it will be removed at some point (which I still feel would the correct approach) Including an -L flag for libraries, which only read :extra-deps (ignores :main-opts, :exec-fn, etc) would feel far more consistent to the other flags -X -M -P -T which are very representative of their purpose


-A is for adding aliases to the classpath. Originally -A + :main-opts would execute the program. That behavior is deprecated, not -A itself. For invoking main-opts you should use -M. It would be more consistent now if the main function would not be invoked with -A and the REPL would be started with the alias deps.

Alex Miller (Clojure team)14:02:38

Maybe I'll finally do this when we switch to 1.11 version

👍 3
🎉 1

Currently -A, -M and -X all add aliases to the classpath, although each execution operation should result in different outcome (otherwise why would an execution option be there). It is unfortunate that -A behaves almost like -M with a warning added to use -M Defining -A as adding aliases inst really elaborating on its purpose, although that seems to have been the original concept before all of the other flags were introduced. Chaining aliases with -M is my typical way to include multiple aliases with :main-opts, with only the last alias passing the :main-opts to clojure.main. That is documented and works consistently for me. It was strange to adapt to initially though. Using a :lib/thing alias naming is a meaningful convention use in the practicalli/clojure-deps-edn user level configuration to clarify the use of the alias, aiming to make the overall clojure command easier to understand. A :lib/ and :src/ qualifier help distinguish adding an extra library or source with other aliases that will run Clojure code Using -A execution option remains a source of confusing to me, especially when used with -M, as it seems to run the :main-opts from the -A alias on the few occasions I've used it. I haven't felt the need to use -A in a long time and replace it with -M almost automatically now. Where I see -A used with -M I also tend to combine the -A alias into the -M alias chain. Hence the opinion -A should be deprecated. O at least replaced with something that has a clearer purpose that is not complected with the past. This is only my opinion.

Alex Miller (Clojure team)14:02:07

-A is the only way to pass aliases when starting a repl, so it's not going away


Sorry, I am unsure I understand this fully. Are you talking about an implementation detail? Otherwise, I am confused. If running the clojure or clj command, then I can pass an alias to the REPL using the -M execution argument and the REPL will start so long as the alias does not contain a :main-opts key and value. I use the Rebel Readline termnal UI for a REPL I regularly pass aliases in with the -M flag also and so long as repl/rebel alias is last in the chain all the aliases will load their :extra-paths and :extra-deps I am concerned I am missing something fundamental in the use of Clojure CLI now

Alex Miller (Clojure team)17:02:04

while you can start a repl that way (as a particular execution of clojure.main via -M), we have stated that using clojure without a "mode" (-M / -X / -T) is how you start a repl with the CLI

Alex Miller (Clojure team)17:02:00

if you want to also supply aliases when starting a repl, you do that with -A

Alex Miller (Clojure team)17:02:41

from clj -h:

  Start a REPL  clj     [clj-opt*] [-Aaliases] [init-opt*]
  Exec fn(s)    clojure [clj-opt*] -X[aliases] a/fn? [kpath v]* kv-map?
  Run tool      clojure [clj-opt*] -T[name|aliases] a/fn [kpath v] kv-map?
  Run main      clojure [clj-opt*] -M[aliases] [init-opt*] [main-opt] [arg*]
  Prepare       clojure [clj-opt*] -P [other exec opts]

Alex Miller (Clojure team)17:02:28

while clj is the same as clj -M -r right now, it may not always be so

Alex Miller (Clojure team)17:02:07

and clj w/o -M etc may in the future take other (new) arguments


So -A is the official way to pass an alias when running a REPL with clojure or clj. Other approaches are not guaranteed to work Okay, that makes sense. However, I never use clj or clojure to start a REPL by themselves, or with -A. I always go through -M, for both rebel readline and CIDER jack-in (and running a REPL with nREPL for cider-connect) I will go away and think about this a lot more as I think there is something that is not sinking in yet. Thanks again for the explanation.

Alex Miller (Clojure team)19:02:10

> I always go through -M, for both rebel readline and CIDER jack-in why?

Alex Miller (Clojure team)19:02:53

(one reason would be using -i or -e args)

Alex Miller (Clojure team)19:02:08

being able to pass those to clj without -M is deprecated and will eventually go away (which highlights that this is different than -M -r)


Why use -M CIDER jack-in uses :main-opts to run a REPL, I believe to support nREPL. I also use -M to run a REPL with nREPL (headless or with figwheel-main) via a separate command line for CIDER connect Figwheel-main also seems to require :main-opts to run, so -M is used I haven't looked at the inner workings of the projects for a while, so don't have more details at hand I haven't used -A since the depreciation warning always added I haven't really used -i or -e flags, except for abandoned experiments. If I should be doing something else, it's really not obvious to me, sorry.

Alex Miller (Clojure team)13:02:45

If you're using main-opts then you should be using -M (but I suspect you are really running a program that happens to implement the client side of a remote repl) vs using clojure.main’s to start a terminal repl in these cases, which is the point of the non -M repl


nREPL can provide a client to a REPL process when run in interactive mode. I assume this is what CIDER is doing or it has implemented its own client that communicates over nREPL. Rebel readline replaces the client ui that would otherwise be created with clojure , to provide additional features I do not use the specific case of running a REPL process and prompt with the clojure binary (or clj wrapper). So it would seem -A is not currently part of my workflow as I dont run a REPL prompt in that way. Once the -A flag removes :main-opts support, then it would seem only the -M execution option is the only way nREPL & CIDER will work as the aliases include :main-opts. This assumes -M does not change in a way that breaks nREPL & CIDER. If this is incorrect, I am afraid I do not know what is correct. I am sure this is taking up too much of your time, so unless there is an alternative I'll stick with -M until I have more time to investigate this. Thank you.

Alex Miller (Clojure team)12:03:05

That all seems correct

👍 1

Has the Clojure homebrew tap moved recently? The docs (and our internal scripts) reference

brew install clojure/tools/clojure
but the repo is at I'm having trouble getting Homebrew to realise that the repo has moved, even after removing the old tap it still rewrites clojure/homebrew-tools/clojure to clojure/tools/clojure when using a Brewfile e.g.
tap "clojure/homebrew-tools"
brew "clojure/homebrew-tools/clojure"
$ brew bundle
Using clojure/tools
Using clojure/tools/clojure
Makes me think there is some other config or cache somewhere that Homebrew is still holding on to.


The repo hasn't moved. a tap clojure/tools translates into a git repo named clojure/homebrew-tools. the homebrew- prefix is required by homebrew in the git repo but does not appear in the tap name.


Ah, thanks! Didn't realise it did the translation. Root of the issue for us is that brew bundle doesn't automatically create taps for clojure/tools/clojure, but brew install does, so our Brewfile was partly broken if you hadn't installed some of the taps yourself previously.


Q: is it possible to use an alias from a dependency libs deps.edn? Can’t find any way to do this except duplicate the aliases in the top level deps.edn


seems like it would be a useful feature so I assumed it was possible but I can’t figure out how


have been searching but can’t find any clue there


I use Cursive and it allows a project to enable aliases from libs but, both in cursive and from the cli, when I print via -Sdeps tree, extra deps enabled by the alias are not present. Pretty sure this is a tools.deps question but I suppose it’s related to Cursive as well since it exposes the aliases in its UI @U0567Q30W


I’m testing without Cursive, just in terminal. when doing that, it reports that the alias is “WARNING: Specified aliases are undeclared and are not being used”


No, you can't invoke aliases from dependencies. But it is a frequently requested feature.

seancorfield22:02:57 should have a few issues around that which you could go vote for.


thanks. that’s good to know. @U0567Q30W why does Cursive expose aliases from deps libs?


@U0510KXTU You mean in the Deps toolwindow? That’s because you can only enable the aliases project-wide there to control the synchronisation of the whole project (project in the IntelliJ sense, probably made up of lots of deps modules). No-one so far has requested being able to control that on a per-module basis. FWIW that’s what Maven does with profiles, too.


ok. maybe my workflow is unique but I don’t think so. when I see aliases from dependencies and I enable them, I see the jars appear in the classpath which is expected. but when I try to load them in the repl, they are not available. that is confusing. am I thinking about this wrong?


(yes deps tool window)


I don’t think I need “per module” features. Just finding the UX confusing


from Seans response I know that I need to duplicate any aliases in the top level project. that will mean I see 2 aliases for each I’m using in the deps window as well


happy to demo if I’m not explaining well