Clojure's classloader looks for .clj files and compiles them when needed. I think you will need it. Passing the (prior) classloader to it as a parameter enables it to extend, as it were, whatever the prior classloader chain had been doing.

I phrased my original question badly. I've been using a custom REPL implementation that retains the classloader of the original REPL for years without any ill effects. I've only ever started that custom implementation from within an existing clojure.main REPL, though. Now that I think about it, maybe installing a new classloader is only relevant in cases where it's necessary to return to the original, top-level REPL. I'm still not sure in what practical reason there is for installing a new classloader for each nested REPL.

It seems cautious to at least make sure that the parent CL is a DynamicClassLoader, and not a default one. But yeah avoiding an abundance of CLs is a good idea, nREPL does that

Oh yeah, you're right, that's probably what that's about: ensuring that the context classloader is a DynamicClassLoader. 👍 Since I know I'm always going to be on top of a clojure.main REPL, I probably don't need to do that.

When I was using the Socket REPL Server (and Chlorine/Clover for my editor integrations), it did not use a DCL by default so you couldn't add new dependencies to the running REPL -- so I had an alias that enabled a DCL like that code in clojure.main/repl when starting a Socket REPL Server.

Found the old alias/code: https://github.com/seancorfield/dot-clojure/commit/b343b848966bb819469725314e7a4de332e074b2#diff-551f87f7577a57c2f4f74b35056d5c7985331f7a38976810fd2bbc213bfe7bb5L139

(and also lines 62-63 of dev/repl.clj in the diff block just below that)

I am interested in Clojure in devcontainers, when using Clojure with python / R . I am wondering which advantage devcontainer in a pure Clojure project bring. Can you explain a bit your use case ?

I work on a number of different projects, frequently with others. Devcontainers give you a clean and common environment, that can still be customized, by running one command. Rather than documentation that drifts out of date, and everyone with a different setup, you can all have a copy of the same system, while still being able to customize it.

Especially as a project grows and acquires tools and scripts, it makes it worlds easier to collaborate.

Much of what I've learned is just trial and error, so I'm trying to document it so that people don't have to rediscover the wheel each time.

It is also super handy to experiment with new libraries, as you can setup sample data, which lowers friction with people just getting started.

<https://clojuredocs.org/clojure.core/*print-namespace-maps*|https://clojuredocs.org/clojure.core/>*<https://clojuredocs.org/clojure.core/*print-namespace-maps*|print-namespace-maps>*

What you’re seeing is likely an nrepl / middleware thing

why does it matter if they're equivalent?

@U02EA2T7FEH It's odd, I'm running the same command from the terminal in all machines, no REPL involved, even using Nix to homogenize the env :thinking_face: @U050ECB92 I have a very simple task that compares files by textual representation and I'd like to keep it that simple

They're not really equivalent though, namespace maps are completely unreadable

?

they're not edn readable, but they are clojure-reader readable

Yeah, sorry, this was a very personal opinion, not relevant to the topic.

yeah I don't enjoy them myself, but I couldn't tell what your angle was from your comment 🙂

Is it worth a switch to pp? https://clojurians.slack.com/archives/C06MAR553/p1696484366516659

I would be very surprised if this was the case. My suspicion is that the differences in the printing of the maps arises due to some other difference between your local machine and ci

like that is the kind of thing that would make me worried the ci server is using a different set of deps for some reason

@U05VAB0RW4C Interesting alternative, I'll give it a go @U0NCTKEV8 It must be, but it is far from obvious (even more so that we are using Nix for having a reproducible env) :thinking_face: Well I suppose the easiest fix is to systematically bind *print-namespace-maps*, it's just slightly suboptimal 🙂

pp won't make a difference here; it obeys *print-namespace-maps* the same as clojure.pprint/pprint.

Can you share the CLI invocation / code you're using where you see this inconsistent behavior?

@U4ZDX466T I'm simply invoking a function as a Babashka task which does some data manipulations and eventually pprint the output. @U04V15CAJ I don't suppose Babashka does anything special with *print-namespace-maps*?

Of course there could be an inconsistency somewhere in bb vs clj. Feel free to provide a repro when you find one