can a deps.edn provide jvm-opts for default calls, without having to specify an alias?

No

is that intentional, or a maybe-future-feature?

Maybe future

But it seems weird that all clj invocations in a project would share those

Which is why I haven’t added it yet

when imagining it was intentional I started thinking that maybe for a nontrivial project clojure isn't meant to be called directly, and you'd setup bin/ scripts that call clojure with appropriate aliases

at least for running specific code; maybe it's fine for launching a repl

Like maybe it would make more sense if it was scoped only to running a repl

Or running a specific main

yeah, specific main would definitely be adequate for anything I want to do

But if you’re doing that, don’t you already have an alias where you can put it?

Or is it that you don’t want to repeat it in aliases

hmm, you're right, I guess a human typing in a main ns might not be very common so my particular situation, which is maybe not common enough to be worth targeting, is that my "project" mostly consists of a monolithic clj file at the root, and I just run clojure code.clj a lot but I'd like to have it with a restricted -Xmx by default, and can't do that; I just have to remember to run clojure -Afoo code.clj instead

I think "stop being weird" is a perfectly good answer here, I was just curious

Or even just clojure -A:foo since you could add code.clj to the alias (as a :main-opts element), right?

[email protected]:/mnt/c/Users/seanc/clojure/foo$ cat code.clj
(println "Hello from code.clj")
[email protected]:/mnt/c/Users/seanc/clojure/foo$ cat deps.edn
{:aliases {:foo {:main-opts ["code.clj"]}}}
[email protected]:/mnt/c/Users/seanc/clojure/foo$ clojure -A:foo
Hello from code.clj
[email protected]:/mnt/c/Users/seanc/clojure/foo$

If tools.deps exposed a :init-opts option in deps.edn, that would remove the need for multiple mains. Most uses (I've had) involve side-effects like launching an nrepl for personal dev purposes. If I use a main for that, I can't use a project-specific main.

:main-opts can contain -e and -i -- and you can combine multiple :main-opts from multiple aliases @dominicm

That's partly why I separate out :test and :runner for example.

I admit, I do miss the ability of combining aliases in other aliases -- that's probably the thing that would add the most ergonomic utility for me. That's really why we have a shell script wrapped around clojure: to do some "alias expansion"

@seancorfield you can only have one :main-opts active from an alias at a time.

Compare with jvm-opts which does concatenate.

Ugh! Yeah, you're right. I'd convinced myself they combine...

Which means I change I made recently to my dot-clojure file doesn't actually work.

(well, it does work, but not quite how I thought and it explains why I still need a manual step at the end)

So, yeah, you've now convinced me that having an :init-opts for just "init opts" that actually combined like :jvm-opts would be a good thing 🙂

(or, frankly, even if :main-opts itself combined and it was just "caveat programmer" to use it that way)

The problem with main opts composing is that there's an order problem. Not so with init-opts. I suppose people may also be relying on the fact that main-opts conflict.

If you have multi -e options you might want them to execute in a particular order 🙂

I added -e to my :deps alias to set up a DCL, so that if you do -A:deps:socket then you get a DCL in place before the Socket REPL is created so you able to use add-lib via Atom.

But if you do -A:deps:socket:rebl-11 you get a REBL window without DCL 😞

So you have to do -A:deps:socket -R:rebl-11 -r (omitting the :main-opts from REBL) and that sets up a DCL and starts a Socket REPL and finally starts a command-line REPL... and in there you can do ((requiring-resolve 'cognitect.rebl/ui)) to start the REBL window and then it does have a DCL.

(this is all a workaround because Socket REPLs don't use DCLs by default)

@seancorfield my implementation of this in user space might interest you. You set properties using jvm opts, then have a main which reads those properties and runs evaluations from them.

Implementation is a little strong perhaps. Idea :).

Re init opts, at some point you’re programming, just write a clj and call it

Well, that was why, in the end, we wrote our little dev/repl.clj script at work -- it looks at what's on the classpath and starts a Socket REPL, an nREPL Server, REBL, or a regular REPL.