This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-21
Channels
- # announcements (51)
- # asami (5)
- # babashka (25)
- # babashka-sci-dev (26)
- # beginners (33)
- # calva (10)
- # clj-kondo (51)
- # clj-yaml (99)
- # clojure (96)
- # clojure-australia (3)
- # clojure-berlin (5)
- # clojure-europe (151)
- # clojure-norway (58)
- # clojurescript (20)
- # cursive (13)
- # datalevin (1)
- # datomic (19)
- # docker (6)
- # emacs (55)
- # events (1)
- # fulcro (50)
- # gratitude (8)
- # juxt (7)
- # leiningen (5)
- # malli (6)
- # membrane (1)
- # nbb (28)
- # off-topic (22)
- # pathom (7)
- # polylith (20)
- # portal (1)
- # reagent (37)
- # reitit (2)
- # releases (2)
- # reveal (32)
- # scittle (34)
- # shadow-cljs (46)
- # testing (10)
- # tools-deps (33)
- # xtdb (18)
Does tools.deps have something equivalent to Leiningen's :injections
? I think what that does is to inject requires in all namespaces, but I am actually not sure. In any case if I am using tool that has instructions to specify :injections
for Leiningen, what could some equivalent thing be with tools.deps?
it doesn't, but I wrote up an example of how to do modify your repl at https://insideclojure.org/2020/02/11/custom-repl/
(the commas in the alias there are no longer necessary though, that's been fixed)
Very funny result trying that custom repl in Calva, @alexmiller 😃 Is it nREPL that isn't a true REPL enough, maybe?
Well yeah, nrepl is not a true repl so will not work with that
I remember reading an in depth breakdown of why this is so. Do you happen to have a link to it at hand?
I think that's the one, thanks. This got me thinking again about listeners. How would that work in Clojure?
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
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.
@pez You could make your own evil middleware with nREPL but you didn't hear this from me
I'm looking at https://github.com/clojure/brew-install/blob/1.11.0/deps.edn and notice that it depends on org.clojure/tools.deps.alpha
but clojure.exec.run
says that it only depends on Clojure's core https://github.com/clojure/brew-install/blob/1.11.0/src/main/clojure/clojure/run/exec.clj#L11 -- I was thinking of depending on this as a git dep to get access to the exec fn stuff but that would drag in t.d.a. Should that dependency actually be in there?
I guess I could use :exclusions
to prevent it dragging in t.d.a (and slf4j-nop) but...
(background: we have an exec-command
function at work in our build.clj
that allows us to set up and run Java processes that pass exec args etc but it currently relies on exec.jar
as a local dep because we have it vendored into our repo -- and I'd like to open source this, likely as part of my build-clj
wrapper, which means it needs to operate independently of where the CLI is installed...)
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