we could just expose the SCI API to nbb

After looking at the nbb code and seeing how it uses sci, I suppose another option is to use sci directly. I'd only need to evaluate a single short file (maybe with some common functions injected), no async. Maybe I could do a simplified version of eval-next https://github.com/babashka/nbb/blob/main/src/nbb/core.cljs#L383

@U066LQXPZ In this case, you might just want to use SCI directly in a bespoke CLJS project and compile it to JS with the interface you like

Ah, right, all of that API isn't available to JS.

There used to be a JS api, but it was a pain to maintain

Ah, I guess that's why those docs are commented out in the README. They still show up on https://www.npmjs.com/package/@borkdude/sci

it's not a good habit to remove npm packages, is it? ;)

No, probably not, though I see now that it's pretty old compared to the latest sci release.

Maybe add some notice?

Does npm support archiving / deprecating a project?

I don't know, haven't worked with it from that end.

Looks like it meets the criteria for being unpublished: https://docs.npmjs.com/policies/unpublish

done

I wonder who will start complaining...

maybe I should have checked the usages first :/

It said there were zero dependents.

oh I think it's ok ;) https://github.com/babashka/sci/network/dependents

anyway, one should probably upgrade to the newest SCI instead of using one from 3 years ago

Back to the original question...would you anticipate any problems pushing sci options through something like nbb.loadFile?

That's not what I plan to support, but what I would support is this:

(nbb.loadString `(require '[sci.core :as sci]) (sci/eval-string "{yourProgram}")`)

I'll have to think about it. It's just a simple script returning one function and some data, and then the potential execution of the function. I'm trying to pitch this as giving a really easy user experience (despite being Clojure 😜). But I'm just in the initial stages of thinking about this, so there's opportunity to adapt. For selling it to the team, it would be a big win if it was "just a library". If we're going to go full VM or similar, we'd probably just go JS for this.

I didn't mean VM as in a dedicated virtual machine

I meant a Node.js vm, it's an built-in sandboxing-like thing

Just try npx nbb, then (range) and then hit ctrl-c. This is implemented with the Node.js vm library

Ah, cool, will check that out. Thanks!

That's good to know about, though I think it comes back to the same thing, where if that's the only safety mechanism we might as well just use JS. I'll see where I can get calling sci from inside nbb.

yeah, I think we could maybe support load-string or so with extra SCI opts but maybe not exposed via the normal namespace. Feel free to experiment locally and see how far you get

From nbb running jacked-in from calva:

(require '[sci.core :as sci])
(sci/eval-string "(inc 1)")  ; => Could not resolve symbol: sci/eval-string

Actually, maybe require didn't work. I tried it again and the first time it gave Could not resolve symbol: -invoke, subsequently nil.

$ nbb
Welcome to nbb v1.1.150!
user=> (require '[sci.core :as sci])
"Error: Could not find namespace: sci.core"

sci itself needs to be exposed through the sci options