Nice blog post dude!

This one right? (I lost the timing): https://news.ycombinator.com/item?id=28982952

Correct

@U9ES37CSZ has a similar request recently: This is what I replied: > Hey there! Can you please let me know if it's possible to have two projects sitting next to each other, with a `bb.edn` file in each of them, and one project's tasks to depend on tasks from the other project? > This is currently not yet supported (similar to how you cannot do this with Makefiles). But you can have one root `bb.edn` and use `:dir` to execute shell and clojure commands in subdirectories, if that helps It might be worth exploring but it comes with additional complexities so there is a trade-off between additional complexity and convenience. • The classpaths from both bb.edns should be made absolute (src becomes an absolute directory) and appended • :init fragments should be concatenated?

Also there are very likely to be naming clashes between tasks. E.g. in the repo you are speaking of there are a couple of dev tasks. If you merge those, which dev task will you pick? You will pick one and lose the others.

I'm not asking about a single project with merged stuff

I would like to be able to discover and call bb tasks from the root

each task will be executed with it's own bb

ok, but even then. in the DRE monorepo, if you execute bb dev , there are three tasks in those sub dirs

which one do you pick?

of course, it's tempting to have the approach you described, and it's more pwerfull in some scenarios - but it comes with stuff attached

like I mentioned, each task has a path

as a convenience if you have only one dev task in all your subprojects you could call that by short name

otherwise only full path - maybe allow for aliasing to have shorter names ?!

so bb app:deploy:dev

(cd app; bb dev)

$ bb tasks

build
publish-image
app:build
app:publish-image

the issue is with discoverability

people (esp new people) don't know where they

@U011NGC5FFY Let's post this idea in Github Discussions so we can think about it and more people can chime in. This may sound easy but I'm sure it comes with edge cases, I'm mostly worried about those, before settling on anything. This specific feature is probably something you can build using a root bb.edn that has one task per repo and gives an overview of the specific repo + the option to invoke a task in that repo.

{:tasks {:requires ([clojure.string :as str])
         app {:doc "Without arguments, prints tasks in app - with arguments, invokes task in app dir"
              :task (if (empty? *command-line-args*)
                      (shell {:dir "app"} "bb tasks")
                      (shell {:dir "app"} (str "bb run " (str/join " " *command-line-args*))))}}}

This isn't a lot of code, and gives you more flexibility as well

@U011NGC5FFY I added one now in the DRE repo. Type bb app in the root and e.g. bb app dev

I really like Eugen's idea about

build
publish-image
app:build
app:publish-image

@U9ES37CSZ With the above snippet you get:

bb app ;; prints app tasks
bb app build
bb app publish-image

https://github.com/babashka/babashka/discussions/1044

ok, I'll follow up there

I came here to comment after you retweeted. This is a huge deal Michiel! Well done

This is really neat, congrats! :)

nice!

bb is already really a game changer for me. Being able to code with the comfort of clojure in this "scripty" niche is immensely liberating. And it works well + the creator is available on slack for questions 😛

@UBTMXD33J map is lazy, for causing side effects you could use run!

just replace it with that function, it should work

or realize the lazy sequence with doall but if you do not use the result then run! or doseq is better

Thank you, it works now

What does ssh have to do with babashka.fs? Do you mean babashka.process perhaps?

oh yes!

typo

edited

Try this:

bb -e '(-> (babashka.process/process ["ssh" "user@host"] {:in "ls" :out :string}) deref :out)'

that worked! any way I can achieve this through the repl?

The same expression should work in the REPL

just tried. perfect. thanks so much @U04V15CAJ

cool. Note that you can use :out :inherit if you just want to print the output from ssh as you execute it

sg!

if I chain processes will those stay ssh’d?

in the same expression

each call to process will create a new OS process so it will result in a new ssh session

note that you can write to the inputputstream multiple times as well

like here? https://github.com/babashka/process#feeding-input

Like this:

(require '[babashka.process :refer [process]]
         '[ :as io])

(let [ssh-process (process ["ssh" "user@host"] {:out :inherit})
      in (:in ssh-process)]
  (with-open [in (io/writer in)]
    (binding [*out* in]
      (println "ls")
      (println "whoami")))
  (deref ssh-process))

nil

so I'm writing ls first and then whoami

thanks again and did something that was long overdue

Thanks a lot :)

thank you!

the message format is encoded in bencode, just to have some common format for all pods. then inside of that you can encode the payload using json, edn or transit. Bencode is used to not force either one of these formats on the pod

Aha!

> Bencode is used to not force either one of these formats on the pod My spontaneous reaction.. this is brilliant 💎