That also means that any (uber) JAR started via java -cp the.jar clojure.main -m my.entry.point will also have *repl* true I think and therefore could use add-lib?

I wondered about this too

yeah, that should have been more scoped

my bad

what about just removing this var and just add warnings to the docstrings of clojure.repl/add-lib etc (clojure.repl already indicates that it's for REPL use only)

that was another option considered, we chose this

The trouble is, to make this work for most IDEs/editors, it really has to be available with -m because that's how "everyone" starts REPLs these days. Unless all of that tooling is updated to bind clojure.core/*repl* to true -- and we know how slow that tooling has been to adopt all of the other work around clojure.main such as exception/stacktrace handling 😞

I think, perhaps, a JVM property that turns it off might be sufficient to address people's concerns?

(I just posted a similar thought to Ask, but about disabling user.clj auto-loading since that seems to bite people a lot -- and in fact bit someone trying out add-lib today because invoke-tool still caused user.clj to get loaded, and it output stuff that broke the add-lib function somehow)

Anyways, this is why we have Alphas 🙂

yeah

> That also means that any (uber) JAR started via java -cp the.jar clojure.main -m my.entry.point will also have *repl* true I think and therefore could use add-lib? I was wrong about this: although such usage would have *repl* bound to true, starting the process via java means that the basis is not available and these features also assume they can shell out to the clojure command on the host -- so all of this new functionality is only available in processes started via the Clojure CLI itself, not via java.