This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # asami (5)
- # beginners (22)
- # biff (2)
- # cider (1)
- # clara (3)
- # clojure (17)
- # clojure-europe (7)
- # clojurescript (29)
- # core-async (2)
- # datahike (1)
- # fulcro (11)
- # gratitude (2)
- # integrant (2)
- # lsp (6)
- # music (2)
- # observability (1)
- # off-topic (36)
- # polylith (4)
- # quil (2)
- # reagent (15)
- # tools-deps (36)
- # xtdb (16)
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.
Maybe I'll finally do this when we switch to 1.11 version
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.
: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
: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.
-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
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
I am concerned I am missing something fundamental in the use of Clojure CLI now
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
if you want to also supply aliases when starting a repl, you do that with -A
Usage: 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]
clj is the same as
clj -M -r right now, it may not always be so
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
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.
> I always go through -M, for both rebel readline and CIDER jack-in why?
(one reason would be using -i or -e args)
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.
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.
That all seems correct
Maybe I'll finally do this when we switch to 1.11 version
Has the Clojure homebrew tap moved recently? The docs (and our internal scripts) reference
but the repo is at https://github.com/clojure/homebrew-tools. I'm having trouble getting Homebrew to realise that the repo has moved, even after removing the old tap it still rewrites
brew install clojure/tools/clojure
clojure/tools/clojurewhen using a
tap "clojure/homebrew-tools" brew "clojure/homebrew-tools/clojure"
Makes me think there is some other config or cache somewhere that Homebrew is still holding on to.
$ brew bundle Using clojure/tools Using clojure/tools/clojure
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
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 https://clojure.org/reference/deps_and_cli#_aliases 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.
http://ask.clojure.org 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?
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