One idea could be to namespace by directory e.g. nbb-features/%s/deps.edn. We could also namespace by file e.g. nbb_feature_%s_deps.edn but I don't know if clj handles deps.edn files with unconvential names

The deps.edn should not matter since those deps would already be on the classpath. The idea is: being on the classpath, means you want to use that feature. The only thing that matters is the nbb_feature.edn file and that can be self-descriptive with some shadow config inside of it

going to sleep now

Having no $NBB_FEATURES means we'll have slightly different versions of https://github.com/babashka/nbb/blob/613902dadb8f4ecec384a6a74b1440f356f3f2a3/src/nbb/macros.clj#L25-L35 for bb and clj but that's ok. Is nbb_features.edn still a vector? Would the shadow-config just be :shadow-config {...} alongside the other keys in nbb_features.edn?

I can try this out tomorrow. Some other questions: • Would just the bb compile task be made available as a lib to downstream feature repos like nbb-logseq? • Where's the new file for the bb task lib? • What happens to the datascript and datascript-transit features that ship with nbb? I guess they get added as a dep using :deps/root? Would it be helpful to have a separate nbb-features repo that takes contributions liberally? Could be helpful to nbb users to have a set of features that are easy to drop in to a deps.edn

Mornin! Any opinions on the above? If not, I can give it a best effort and then tweak later if you have feedback

I'm finally awake again, let me think right now and I'll come back

I think yes to most of the above.

What we could also do is build the build of nbb as a nbb script ;)

but this will be harder to deal with .jar files and such, so let's stay with bb

> What happens to the datascript and datascript-transit features that ship with nbb? I think we could port that to the "new" approach

Tests of datascript can be moved out to the features repo. I think that the feature repo can test its own feature in CI

And the factored out build library should test at least one feature to test the concept

> Would it be helpful to have a separate nbb-features repo that takes contributions liberally? Yes, we could just move everything to there

This could be a repo under babashka and I can make you a contributor there so you can push without my permission

Any unanswered questions?

> What we could also do is build the build of nbb as a nbb script 😉 That would be cool some day > This could be a repo under babashka and I can make you a contributor there so you can push without my permission Cool Any preference on where the build library is? I was thinking script/nbb/build.clj

Sure, but how do we "share" the build library?

We could also put it in nbb/build/deps.edn , nbb/build/src/...

and then use deps/root (externally) and local/root (within nbb) to get the lib

I thought it would just be a git dep. I'm guessing that would require modifying :paths in deps.edn which probably isn't desirable

separate root sounds good

This sounds like it's going to be very extensible which is good!

Indeed! Excited to see how this goes

Any ideas on how the bb build task would pass its classpath containing feature deps to the clj command running shadow-cljs? I don't see another way than the current dynamic deps.edn approach - https://github.com/babashka/nbb/blob/c3ffa5352b7ab6870e8f909cde10d139bb863ee6/bb.edn#L19-L26

@U08ALHZ2N That works. Another way would be to call (babashka.deps/add-deps ...) on the maps and then use the classpath that is in (babashka.classpath/get-classpath) . But I think your approach might be better

Also faster

since you're not calling the clojure CLI for each feature

Another way could be to emit a deps.edn into a _fake_project folder and then add :local/root "_fake_project"

Hmm. One downside of the current dynamic deps.edn approach is that the dynamic :local/root has to be built from the path of nbb_features.edn. In other words, :local/root has to assume that 'src/nbb_features.edn' relates to :local/root being one directory up

For deps/add-deps to work I think the bb task would have to read from its bb.edn file

you can start another bb instance in another directory

with shell etc

Not sure a I understand. What would the command be? Does bb provide a path to the current bb.edn file or map it's using b/c I think that would work?

Yes: (System/getProperty "babashka.config")

what I mean is that you can start a new babashka in a new temporary directory

and spit out a bb.edn in there

but it remains a hack

K. I think feeding babashka.config to deps/add-depsworks with no obvious downsides. I could then pass the new classpath to shadow with clj -Scp (classpath/get-classpath)

indeed