Is this behavior correct, if just the :test alias contains a main function, but not :sci or :demo should it still pick the main function from :test ? It's kind of annoying since I want to invoke my own main function from the command line while having deps from these aliases and clj -A:... doesn't do what I'd expect either (still)
clj -M:build:test:sci:demo -m shadow.cljs.devtools.cli watch viewersThis is why I often have both a :test and a :runner alias.
It's also why I have a :no-main alias in my user deps.edn: https://github.com/seancorfield/dot-clojure/blob/develop/deps.edn#L37-L39
I was just going to type:
Adding an alias :clear-main {:main-opts []} would solve it but this feels a bit like CSS ;)clj -M:build:test:sci:demo:no-main -m shadow.cljs.devtools.cli watch viewersDoes -X also work like this? if :test has an exec-fn but :demo hasn't, does it still pick the exec-fn from :test? I thought I'd seen different behavior before but could be wrong
:exec-fn is last-one-wins since that option in merge'd
right, I guess it's just merging all the things then
But if you have :test set up to work with -X (only) then you can safely use -M:test without getting stray main opts.
yeah
FWIW I'm open to adding a shadow-cljs "entry" that works with -X, as in takes a map instead of the standard command line arguments
but not really related to the question I guess 😉
Yeah not a big issue, the issue is more general than shadow. I think if -A did nothing more than add a bunch of deps to the classpath, this would be what I used
@alexmiller Maybe when we get to Clojure 1.13, we can have a CLI 1.13.0.xxxx that finally drops :main-opts from -A so it can be used as above? 🙂
That would be great
(that would be a tools.deps change I believe?)
yes, just a tools.deps change, not a clojure change
Well, the CLI needs an update to include that tools.deps change since it's a bundled uberjar, right?
yes, with clojure I mean the language. with tools.deps I roughly meant the CLI + tools.deps
Right, I just meant that it seems like a change that would be unlikely to be made in a 1.12.1.xxxx version since it's a "big" change (and potentially breaking people's workflows if they've been ignoring the deprecation warning). Hence thinking 1.13.0.yyyy would be a good time to make the change.