Clojurians Log v2

Sure. I'll be updating nbb-logseq enough that I should be able to report any custom build issues pretty quick. If I ever make build/ changes, I could also see if there's a clever way to run these tests

Also, thanks for the nbb release and cljs upgrade! Bumping to a release makes it easy for me to bump to the newest nbb

cool. we could also detect if some build code has changed or not, for example

Right. I'm ok with disabling it for now if you'd like to speed up builds

ok, done

Can you tell me how this would apply to babashka? Preferably here: https://github.com/babashka/babashka/discussions/1044 As much detail as possible, better than handwaving :)

done!

Similar to the :subprojects idea I was mentioning and more polished and established approach taken by Rust's Cargo: https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html

that would require you to add a bb.edn in each subdirectory which may not be what you want

well not each one but you can put where its needed, denoting a sub project and the recursive walk would ignore dirs with no bb.edn

ignore that dir and its children

sounds complicated

yeah for me too, its just another thought i had when i read about the reader limitation 😄

Any opinions on this @rahul080327 @cap10morgan @lee?

Ah just the monorepo task listing/invoking part yeah? I was also glancing at the default task idea (which maybe feels like a separate issue? Dunno).

Yes, that's a separate issue

Is this just about task discovery and invoking for monorepos? Nothing more than that?

yep

How deep would bb dig to find bb.edn files? Would it search all subdirs?

That's a good question. Something like this, takes 25 ms in the bb repo:

$ bb -e '(time (map str (fs/glob "." "**/bb.edn")))'
"Elapsed time: 24.973688 msecs"
("sci/bb.edn" "fs/bb.edn" "process/bb.edn")

Curious because I’ve not worked on a monorepo but do have one project with a https://github.com/cljdoc/cljdoc-analyzer/tree/master/modules/metagetta. I wonder if bb would report on this one too when I did a bb tasks

Perhaps some options around subdir searching in a root bb.edn ?

Yes, that would be the idea, to report it as

modules/metagetta/test run all tests

I would say:

bb tasks --subdirs --depth 5

and not do it by default

The idea would be that you can always stay in the root dir of the mono repo and execute all tasks from there

Right… and if you cd downward bb would look from cur dir downward in your monorepo, I would assume.

yeah

Seems like a good idea. Especially the discovery part. What tasks does my monorepo have?

Would it also be interesting to ask in #polylith?

Or do they already have their own solution for this type of thing?

Not sure. I have a similar use case in clerk. I have a directory ui_tests: https://github.com/nextjournal/clerk/tree/main/ui_tests So from the root I could execute my ui_tests using:

bb ui_tests/test

I think people will be confused when they try to re-use tasks from a subdirectory in the upper bb.edn, which imo isn't possible due to the "current working directory" problem

So bb ui_tests/test should work but not (run 'ui_tests/test)

unless that would invoke another bb process as well

Yeah https://github.com/cljdoc/cljdoc-analyzer/blob/e42a7e3ef9fc6732d082f4e913a8318180c44aae/bb.edn#L33-L36

yeah, I'm afraid I would introduce something that is easy on the command line but leads to confusion

Would dependencies still be scoped to a single bb.edn?

yes

there would be no merging of tasks and deps going on, just a way to list them and invoke them

Yeah, good point, because I can do this, why can’t I do that?

I suppose just reporting all tasks and not supporting the running part could still be useful?

Or not?

What if (run 'ui_tests/test:foobar) was synonymous to (shell {:dir "ui_tests"} "bb run test:foobar")

Yeah that would work.

> What if (run 'ui_tests/test:foobar) was synonymous to `(shell {:dir "ui_tests"} "bb run test:foobar") > ` This is pretty much what I do in my monorepos. This is the https://github.com/bob-cd/bob where i use it. Just that I have long names without a - delimiter. Would / as a delimiter be allowed as a normal task name and later on there's a folder with the same name and this has a different behavior? / is quite idiomatic namespacing in clj?

My personal preference would be to denote the subdir explicitly rather than a naming convention

Like bb subtask-run ui_tests/test:foobar or something. Similarly (subtask-run 'ui_tests/test:foobar)

If thats the case, I would expect the paths in my sub bb.edn to be relative to it. If its implemented as forking another bb or not could be abstracted?

Task names with slashes are normally not allowed so using a slash would already indicate a subtask

I do think we'd maybe have to use strings if those symbols contain more than one slash as the reader does not accept those

how about a new key in the bb.edn called :subprojects or something? That is a vector of strings showing the dirs where bb.edns are there and can be used when listing and/or running tasks.

Makes sense yes, I like that

I had many a nightmares when using gradle where the nesting is delimited by a : and a bit wary of name based behaviours

unless theres good editor nav support, sometimes quite hard to figure out where this task is

We could also just start with only supporting the command line option and for running within bb you'd still have to use shell, maybe that's less confusing

But (shell bb foo/task) would then set foo as the dir since that is the command line behavior

yeah more i think about it, the decoupling the name from behaviour seems like a nice way to future/confusion proof?

?

What do you mean with decoupling name from behavior?

so having a / in the name could have some sideeffects when shelling or not and some other delimiter like : would make it less semantic i think. so we deciding whether a task is a sub task or not based on its name is the coupling bit im thinking

with the :subprojects key thing, the names are not special

We could also give subprojects an alias even and those aliases can be used before the slash

In subprojects

So then it would not be coupled with the dir structure

Like a group name. Normal tasks could also get an optional group name

what is an example of the alias? cant really imagine it

Usually the name of the subproject. bb foo/test

Foo would be the alias here for sub dir foobarfoouglylongname

and if we have 2 or more levels of subdir nesting that should work here too i guess? im imagining a key called :aliases which is a map of keyword -> str? val is the potentially nested path.

parallel thought: also maybe we could limit it to one level nesting in the paths. the nested bb.edn could have a sub nested task which we can recursively discover. that way i think we can be in the reader's rules?