I remember reading an in depth breakdown of why this is so. Do you happen to have a link to it at hand?

@UK0810AQ2 https://groups.google.com/g/clojure-dev/c/Dl3Stw5iRVA/m/IHoVWiJz5UIJ

Not sure if that’s what you were thinking of, but there’s lots of discussion there.

I think that's the one, thanks. This got me thinking again about listeners. How would that work in Clojure?

What sort of listeners do you mean?

If I'm getting it right, a Listener is just a generic REPL interface with arbitrary read/print methods, including graphical, all connected to the same process. It's an interface by which the process sets up REPLs which listen to input

https://mobile.twitter.com/RainerJoswig/status/1220457695414771714

I really wish CL didn’t have such a high bar to entry. I’m sure there’s a lot to learn there, but I don’t have a year to spare.

@UK0810AQ2 I think tap> has radically opened up the way multiple processes can "listen" to evaluations happening in a core process now.

For a long time, I worked with just a Socket REPL -- and Chlorine (Atom) and then Clover (VS Code) -- but the pace of evolution of Calva (and lack of progress on Clover) made me switch over completely a while back to nREPL + CIDER middleware. I'm still not convinced about the latter. Calva "relies on CIDER" for some functionality but, I'll be honest, I haven't figured out what yet and the middleware just makes stacktraces so much worse so I may go back to plain nREPL soon.

But I just wish I didn't even need nREPL. I wish maintainers of editor plugins were more committed to supporting Socket REPL. One particular use case where this matters deeply to me is being able to connect your editor to a remote Clojure process (or even a remote non-Clojure process that contains the Clojure runtime as a library), where a Socket REPL is started as a JVM option. No dependencies required at all. Right now, the heavy dependence on nREPL means I a) need nREPL as a production dependency and b) need some code in all my apps to start an nREPL server based on, say, a JVM property and c) I need to provide that "non-standard" JVM property -- rather than zero dependencies and an official, core, documented JVM property that works with any Clojure-containing process. Sure nREPL has no other dependencies but it's still an extra 67K to drag around.

Taps feel about 25% of the way there. You can listen on outputs, but input source is indiscriminate. I wish there was more work to close this gap in tools, but most effort is directed elsewhere at the moment

Right, each distinct input needs it's own REPL essentially. But you can use tap> to have multiple "listeners" for the same core evaluation. I think a combination of the two can reach most use cases -- but there are some interactive uses where REPL (or pREPL) alone are claimed not to be sufficient: very large output (including infinite output) and very long-running processes -- where folks say (rightly) that it is important to be able to limit/interrupt the evaluation and/or "printing" the output.

We have intentionally not packaged or committed to any specific api for the exec stuff

And I have changed it in breaking ways several times as it has evolved

I do want to make it accessible and it probably will be a separate lib (or inside Clojure) in the future

So, I do not have an answer for you at this time, other than just copying what you need of it and retaining the copyright and license (with the knowledge it may change)

Roughly translated: do not do this. Yet (maybe). Fair enough. Obviously we could just shell out and run clojure -X... with appropriate arguments but it sure would be nice to have something closer to the java-command/`process` stuff built-in.

At least if I used it as a git dep, I could pin to a version, and not have to copy any code, and then I could update the git dep as exec evolves over time (until something like it is released).

I need it in tools.build too (and elsewhere), so I feel your pain

I might try that at work, anyway, to sanity check my idea of no longer depending on the local vendored exec.jar file. Yeah, it's build-clj where I feel the need for this.

It's intentionally not a git dep as I don't want people to depend on it