also curious @borkdude if it’s possible for dynamic variables to work inside of SCI; meaning, if I have a dynamic var outside, will the copied version from copy-ns be appropriately dynamic

anyway cleaning this up will be a great upgrade

yes, dynamic vars will be also dynamic in SCI but they won't be synchronized with the dynamic var they were copied from, you have to do this manually

but it feels like it’d be a great pattern for all of these reagent plugin libraries i’ve been building to following some convention for installing their namespaces into the SCI context. then users can add their own aliases of cousre

would there be a bundle size penalty for copying everything at compile time? maybe not, if I do something like

(defn get-namespaces [{:keys [exclusions]}]
  (-> {'mafs
       (sci/copy-ns mafs (sci/create-ns 'mafs))
       
       'mafs.coordinates
       (sci/copy-ns mafs.coordinates (sci/create-ns 'mafs.coordinates))

       'mafs.plot
       (sci/copy-ns mafs.plot (sci/create-ns 'mafs.plot))

       'mafs.line
       (sci/copy-ns mafs.line (sci/create-ns 'mafs.line))

       'mafs.debug
       (sci/copy-ns mafs.debug (sci/create-ns 'mafs.debug))

       'mafs.vec
       (sci/copy-ns mafs.vec (sci/create-ns 'mafs.vec))}
      (dissoc exclusions)))

You can make these SCI configurations available as an optional dependency, either by putting them inside namespaces that are optional to load or in a different library. I've done that with configs I use frequently here: https://github.com/babashka/sci.configs

Oh, and because it’s cljs … you’re saying just don’t ship the dependency and leave it up to the user

Nice!

@borkdude do you know if that convert above matters at all - like if that optional namespace binds a var with a bunch of different namespaces, and the user only wants 1/100 or something, will that blow up the build?

or is Closure smart enough to trim the unused ones?

closure is smart enough

you can test this yourself using the shadow-cljs build report

TIL, awesome

@borkdude the only thing I’m thinking of adding to this pattern is

(defn install! []
  (sci.ctx-store/swap-ctx!
   sci/merge-opts
   config))

that's what I do a lot too :)

if I made a namespace that actually called this function, the the user wouldn’t have to write any cljs at all, just include emmy.sci-install in their list of required namespaces, and keep stacking namespaces to get more plugins…

is there any merit to that pattern? or is there some way we could take a data config into Clerk, like :plugins, :aliases etc and then generate a cljs file that does this, without the user having to write a cljs file?

I think it might be better to have the explicit install since the namespace loading order matters and there might not be a sci context in the sci ctx-store yet

yeah, you’re right. There is that mysterious side effecting import of Clerk’s sci-env that needs to happen too.

“mysterious” from the perspective of someone experiencing Clojure for the first time via Clerk, I mean