This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-16
Channels
- # announcements (2)
- # asami (124)
- # babashka (30)
- # babashka-sci-dev (73)
- # beginners (40)
- # biff (1)
- # calva (39)
- # clj-kondo (54)
- # clj-otel (1)
- # cljdoc (59)
- # cljs-dev (8)
- # clojars (2)
- # clojure (96)
- # clojure-austin (16)
- # clojure-boston (6)
- # clojure-europe (51)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojure-russia (60)
- # clojure-uk (4)
- # clojurescript (34)
- # community-development (6)
- # cursive (2)
- # datahike (10)
- # datascript (18)
- # emacs (109)
- # etaoin (1)
- # events (3)
- # figwheel-main (41)
- # fulcro (13)
- # helix (4)
- # introduce-yourself (5)
- # jobs (1)
- # leiningen (5)
- # lsp (8)
- # malli (6)
- # meander (7)
- # nrepl (6)
- # off-topic (60)
- # pathom (29)
- # polylith (8)
- # re-frame (5)
- # reitit (1)
- # releases (1)
- # remote-jobs (1)
- # rewrite-clj (33)
- # sci (3)
- # shadow-cljs (3)
- # xtdb (82)
@cldwalker Do you think we could disable the build test on nbb? It's taking an extra minute of build time but if the build doesn't change much, maybe we can do it more cleverly. I liked that the previous build was pretty fast https://app.circleci.com/pipelines/github/babashka/nbb/673/workflows/bb4a8488-7fe4-4597-9c36-462d58fa7dae/jobs/604
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
Here's a thought about invoking tasks in monorepos: https://github.com/babashka/babashka/issues/1219#issuecomment-1128031344
Any opinions on this @U7ERLH6JX @U06FS3DLH @UE21H2HHD?
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).
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
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.
Seems like a good idea. Especially the discovery part. What tasks does my monorepo have?
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
but right now I'm doing that with:
https://github.com/nextjournal/clerk/blob/9a04cf38fd4d7c771071ddc14538da673cd32f4f/bb.edn#L50I 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
yeah, I'm afraid I would introduce something that is easy on the command line but leads to confusion
there would be no merging of tasks and deps going on, just a way to list them and invoke them
I suppose just reporting all tasks and not supporting the running part could still be useful?
What if (run 'ui_tests/test:foobar)
was synonymous to (shell {:dir "ui_tests"} "bb run test:foobar")
> 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.
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?
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
what is an example of the alias? cant really imagine it
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?
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
yeah for me too, its just another thought i had when i read about the reader limitation 😄
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
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 :)