load libraries from .jar files and directories

See - https://github.com/anmonteiro/lumo/blob/6709c9f1b7b342c8108e6ed6e034e19dc786f00b/src/cljs/bundled/lumo/classpath.cljs

• https://github.com/anmonteiro/lumo/blob/6709c9f1b7b342c8108e6ed6e034e19dc786f00b/src/cljs/bundled/lumo/cljs_deps.cljs

We could start with only git deps btw... and port a subset of gitlibs to CLJS. And then require people to only use gitlibs.

Will this support the following case? I have src/abc/core.cljs and in it (ns abc.core) and I want to required this from my main script which is called by nbb.

Yes. We need some sort of classpath implementation for this.

While I am here making unreasonable demands without contributing anything of value, can I ask if this will allow core.async to be supported? I get Error: Could not find namespace cljs.core.async. (as expected).

@chr15m Thanks for the feedback and also for sponsoring me. Feel free to create another issue about this, since cljs.core.async isn't specific to this issue. It might be challenging to make cljs.core.async work with SCI, which is the interpreter that drives evaluation in nbb. But it's worth looking into. I feel this is a bit of a research problem that might take a bit of time.

Also possibly interesting code: https://github.com/eginez/calvin/blob/master/src/main/clojure/eginez/calvin/core.cljs

I found a way to accomplish this with npm alone, as long as the dep itself has a package.json:

https://github.com/borkdude/nbb/blob/f1ec61ec37c2fd70270572145668fec68ab2ed97/examples/sitefox/package.json#L3

Hey @borkdude, do you have some examples about how could I use https://github.com/plumatic/schema with nbb? Thanks for the awesome job!

Is there a high level design for implementing this floating around @borkdude? I'm interested in this issue. After hacking on the "self-contained" npm deps runner I posted in slack, I thought about how a similar scheme could automate the workaround in the dependencies doc.

A sketch of the idea in my head:

• user runs nbb ...
• find nearby nbb.edn with :deps key
• hash :deps map, e.g. asdf1234
• If it doesn't exist, create modules folder in a location, e.g. ~/.nbb/_modules/asdf1234
• Shell out to bb to create uberjar in modules folder, unzip
• Add modules folder to classpath

This is eminently cacheable but could lead to using up extra disk space when :deps change. I think it's at least it's something to iterate on.

@lilactown This is sort of how I would do it too. You would rely on bb or clojure but that may be reasonable.

Experimental work on this is certainly welcome. An nbb.edn with :deps almost seems like a no-brainer.

@omariosouto As for spec: I had an optional npm module for schema but due to CI issues (npm publish failed intermittently) I had to revert this. I also had a similar optional module for malli, but meanwhile, nbb is able to execute malli from source now:

https://github.com/babashka/nbb/tree/main/doc/malli

Using the above work on nbb.edn using malli would become even easier.

We're going with the current nbb.edn approach for now.