link for reference https://clojure.org/reference/deps_and_cli#_execution

i guess i'm not sure what options clojure.main takes, here is clojure main https://clojure.github.io/clojure/clojure.main-api.html#clojure.main/main

ahh the doc string says what else can be passed

main-opt:
 -m, --main ns-name  Call the -main function from namespace w/args
 -r, --repl          Run a repl
 path                Run a script from a file or resource
 -                   Run a script from standard input
 -h, -?, --help      Print this help message and exit

-M tells the Clojure CLI to use clojure.main to run the code (as opposed to clojure.exec) -m defines the namespace that clojure.main should look in for the -main function To me t makes sense to include the -m in the main-opts as the next thing in the list is the namespace

I see the main-opts as a Clojure version of the command line arguments that are passed after -M (and any aliases following -M). Missing out the -m and just having the namespace would make a difference between the command line and the :main-opts configuration (which I would find confusing)

thanks, yeah. I just think i have done anything but use -m. Here is another thing that can be done:

cat foo
(println (+ 1 1))

clj foo
WARNING: Implicit use of clojure.main with options is deprecated, use -M
2

The practicalli/clojure-deps-edn aliases have some additive arguments, but I don't recall using something instead of -m `:repl/cider {:extra-deps {nrepl/nrepl {:mvn/version "1.0.0"} cider/cider-nrepl {:mvn/version "0.28.5"}} :main-opts ["-m" "nrepl.cmdline" "--middleware" "[cider.nrepl/cider-middleware]" "--interactive"]}`

The depreciation message I believe was in part to help move people away from the -A flag and use the more appropriate -M flag, so f -M isn't used then I'd expect to see a depreciation message (unless using -X or -T instead, in which case main-opts sent used anyway)

I use clj -M:build -i build.clj -r to start a REPL in "build" mode. -i runs build.clj as an "init script" and then -r signals that a REPL should be started. At that point I'm in the user ns but build.clj has been loaded so I can do stuff like (build/database-setup {}) or (build/run-tests {:projects '{api auth login]})

Oh interesting, thanks sean.

Thats an interesting alternative to having a user namespace do everything like that. Thanks Sean.

Given the various caveats around user.clj I avoid it completely.

>

clj foo
> WARNING: Implicit use of clojure.main with options is deprecated, use -M
> 2

$ clj -M foo

$ cli -M foo -m "foo.cmdline"

Thanks. I didn't even notice i left the -M off!

@U04V70XH6 what are the caveats of using a user.clj ? (I searched but couldn't find anything) I always define the custom user namespace as dev/user.clj so the dev path has to be explicitly added via alias, controlling when it lads. Would be interested to know what else to be aware of. Thanks.

@U05254DQM I'm surprised you can't find problems talked about in this Slack, since it's come up quite a few times. I'd have to search Slack to give you examples... Maybe later on today if I have time...

@U05254DQM so I had a quick search for user.clj here this morning and found lots of threads with people running into problems with it. It's loaded outside the context of normal code running or a repl: it can swallow errors, many dynamic vars are not bound, it can load code in ways that break regular code in several ways (because of the difference in context). If it accidentally ends up in a library, it can cause all these problems for downstream users (Leiningen briefly had a bug that caused this to happen). Apparently, even the way different editor plugins interact with starting repls can cause user.clj to be problematic (I did not dig into that particular thread).

The startup order seems something to investigate for constraints, as some contexts are not created before a (custom) user namespace is loaded. I am assuming a namespace loaded via an -i flag loads later than the user namespace (hopefully at the end), possibly removing those context constraints (something to investigate at some point). Other concerns seem due to convoluting the user namespace with the application code, which isn't a problem if kept separate. FYI: I'd searched the web and didn't find anything, seemed to be a lot f noise in slack, but found a couple of threads. Thanks.