Enhancement request: fn to add deps map to the classpath

[pmonks]

I realise update-classpath! can be used to achieve this, but it would be handy to have a dedicated fn in the lambdaisland.classpath ns that took a "deps map" (i.e. just the :deps portion of a deps.edn file), and added any missing dependencies described there to the active REPL classpath.

In effect this would emulate what pomegranate does, but with direct support for tda's "deps map" format (as well as things like git/sha coordinates), rather than leiningen's style of coordinates.

In my use case I'm running a clj initiated REPL outside the context of a "project", so there's no deps.edn file present to watch for changes. Instead, I want to try out different libraries by first finding them (e.g. using things like find-deps), downloading them from within the REPL, (requireing them, and then discovering and experimenting with their features. Only afterwards might a deps.edn file come out of that work.

[plexus]

Yes, you can do this with update-classpath!

(update-classpath! {:extra {:deps ....}})

Just wrap that in a helper if that's still too verbose.

[alysbrooks]

@pmonks We're looking at stale issues. I'm a little unclear what you are proposing beyond update-classpath!. Would it take the full :deps section and massage it into the correct format? I'm not sure we need to add the function but documenting how to do it yourself might make sense.

[pmonks]

@alysbrooks pretty much yes. In my case providing a full deps.edn is overkill - all I want to do is provide a list of dependency coordinates and have them added to the running classpath. No aliases, no non-default repositories, none of the other stuff that can be specified in a deps.edn structure. And yes I would envisage that it's a one-liner that simply wraps its input in all that incidental complexity then calls the existing update-classpath! fn.

This is how pomegranate works btw, so as a side benefit it provides a smoother on-ramp for developers coming from that library.