Fork me on GitHub
#babashka-sci-dev
<
2022-04-21
>
cldwalker21:04:34

@borkdude Heyo. Following up on the idea to read all nbb feature files from classpath. The remaining files to do this for would be a feature's deps.edn and shadow-cljs.edn. Given a user's selection of $NBB_FEATURES, how would we know that one of those files maps to a specific nbb feature?

cldwalker21:04:45

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

borkdude21:04:45

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

1
borkdude21:04:20

going to sleep now

šŸ‘ 1
cldwalker22:04:54

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?

cldwalker22:04:59

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

cldwalker13:04:05

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

borkdude13:04:33

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

šŸ‘ 1
borkdude14:04:30

I think yes to most of the above.

borkdude14:04:06

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

borkdude14:04:30

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

borkdude14:04:56

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

borkdude14:04:41

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

borkdude14:04:11

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

šŸ‘ 1
borkdude14:04:45

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

borkdude14:04:11

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

borkdude14:04:30

Any unanswered questions?

cldwalker14:04:33

> 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

borkdude14:04:16

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

borkdude14:04:18

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

borkdude14:04:43

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

cldwalker14:04:20

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

cldwalker14:04:33

separate root sounds good

borkdude14:04:57

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

cldwalker14:04:23

Indeed! Excited to see how this goes

cldwalker19:04:27

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

borkdude19:04:07

@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

borkdude19:04:32

Also faster

borkdude19:04:42

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

borkdude19:04:18

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

cldwalker19:04:25

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

cldwalker19:04:01

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

borkdude19:04:03

you can start another bb instance in another directory

borkdude19:04:15

with shell etc

cldwalker19:04:04

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?

borkdude19:04:16

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

borkdude19:04:41

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

borkdude19:04:47

and spit out a bb.edn in there

borkdude19:04:59

but it remains a hack

cldwalker19:04:34

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)

borkdude19:04:41

indeed

šŸ‘ 1