I thought it was in effect fetching remote code, from git or wherever, and then executing it (or loading it) in the local environment.
I'm just curious to understand the situation better, but which part architecturally strictly needs the JVM? Even with babashka, or on this website, I don't think anything stops me from Frankensteining in an external library in a running REPL. I could technically fetch the content of a library's repo and then copy each file and run its contents (with the ns blocks) in the REPL. Then the library would become locally available (assuming it's a very plain Clojure library that is)
I assume `add-libs` is sort of a convenience wrapper for the same idea
I thought you were referring to https://insideclojure.org/2018/05/04/add-lib/ which is an experimental feature of tools.deps.alpha. But sure, there could be an (add-lib ...) function in this environment which loads some external code.
rereading the link I guess there are some implementation specifics that are JVM. I'm not really familiar with CLJS to say how those translate - but in principle is sounds like it could work on both platforms
add-libs lets you add Java libraries as well, or Clojure libs that themselves depends on Java libs. So for the JVM you need a JVM specific implementation that can pull Java libs. And when adding pure Clojure libs, you're right, it could be from source directly similar to typing it all into the REPL.
For JS, it's a bit more complicated for the Clojure side, because the compiler isn't in the runtime, SCI is interpreting the Clojure code, it is not compiling it to JS and loading it, which makes adding a source pure Clojure lib tricky. But it could possibly be done for compiled Clojure libs and JS libs, that said I think you couldn't use any forms of advance compilation, because that messes up the references. So there's a lot of caveat I think to doing it in JS and that's why it's not done.
Oh okay, I see the distinction. The library would be interpreted and not compiled to JS - and I guess there would be a needless performance penalty. So it wouldn't be of much use outside of this particular scenario.
Nonetheless it seems like something that'd be quite handy for bugreports and sharing code :) One thing I've noticed is that there is friction with writing minimal bugreports/demos/examples. It usually involves making a new repo with a `deps.edn`. Then you gotta push that to github and send a link.. It's all very doable but there is overhead and people don't want to have one off demo repos scattered everywhere for every issues they've responded to on Github. And the people on the other side of the equation don't really wanna pull and execute your mini-repos either. `add-libs` already lets you boil it down to a single file which is great, but having it all in an executable pastebin or forum comment block would mean everyone is seeming the same environment/configuration, same dependencies, same code and the same output.
That said, looking over a few of my projects I do have to admit that pure Clojure dependencies are the minority :)
Dependencies with their own JS or Java dependencies sounds more hairy.. I wasn't even thinking in that direction. I'm sure that's part of why add-libs is still a work in progress
