Fork me on GitHub
#babashka
<
2021-10-27
>
borkdude08:10:02

Babashka currently on the front-page of hackernews :-)

❤️ 13
🎉 8
party-corgi 3
pmooser15:10:36

Nice blog post dude!

❤️ 1
Eugen11:10:59

one issue I have with bb tasks and I hope it gets improved is that bb.edn files are spread across the monorepo and people don't know about the tasks available to them. Drawing inspiration from gradle (that also has tasks) - it has the concept of sub-projects and it can include other builds thus making all tasks accessible from the root via a path - :my-subproject:my-task ( uses semicolon for path separator). Can babasha tasks support something like this ? Should I open an issue ? I woule like to be in monorepo root, do bb tasks and get tasks that are in other subprojects. Also I should be able to call those tasks from the root and they should be executed properly (as from their own dir). Making the tasks available could be done via am include/require mechanism or a dir scan with filters (path is ~ namespace). ( I would pick include and maybe scan could be implemented in lib that produces a list of require bb files) wdyt?

borkdude11:10:42

@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?

borkdude11:10:54

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.

Eugen11:10:12

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

Eugen11:10:27

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

Eugen11:10:38

each task will be executed with it's own bb

borkdude11:10:00

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

borkdude11:10:06

which one do you pick?

Eugen11:10:15

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

Eugen11:10:44

like I mentioned, each task has a path

Eugen11:10:22

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

Eugen11:10:31

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

Eugen11:10:21

so bb app:deploy:dev

borkdude11:10:23

(cd app; bb dev)

Eugen11:10:24

$ bb tasks

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

👍 1
Eugen11:10:47

the issue is with discoverability

Eugen11:10:23

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

borkdude11:10:00

@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.

borkdude11:10:08

{: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*))))}}}

borkdude12:10:35

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

borkdude12:10:55

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

mkarp12:10:14

I really like Eugen's idea about

build
publish-image
app:build
app:publish-image
We do something like this already with a Python task runner and it works really well. Happy to take part in the GitHub discussion too 👍

borkdude12:10:04

@U9ES37CSZ With the above snippet you get:

bb app ;; prints app tasks
bb app build
bb app publish-image
This is literally 5 lines in user space

1
borkdude12:10:40

ok, I'll follow up there

borkdude12:10:54

Babashka on the technology radar of ThoughtWorks : https://www.thoughtworks.com/radar/platforms/babashka :-)

20
bananadance 10
🎉 10
quoll12:10:10

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

viesti16:10:01

This is really neat, congrats! :)

Benjamin16:10:13

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 😛

❤️ 1
kouvas19:10:35

Hi, not sure if it is really related to babashka but i am playing around with it and have an issue. I have this code:

(defn -main
  [& args]
  (let [{:keys [options arguments errors summary]} (parse-opts args cli-options)
        package-name                               (:name options)]
    (selmer/set-resource-path! templates-path)
    (map (fn [[in out]]
         (spit out (selmer/render-file in {:package-name package-name})))
         [["deps.edn.template" "deps.edn"] ["build.xml.template" "build.xml"]])
    (println "done " package-name)))
When I run the executable I get:
~/w/babashka-scripts  ./script.clj --name TestTest
done  TestTest
but my files, deps.edn and build.xml, are not created. What am i missing?

borkdude19:10:30

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

borkdude19:10:51

just replace it with that function, it should work

borkdude19:10:12

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

kouvas19:10:05

Thank you, it works now

denik20:10:11

are the examples of ssh with babashka.process?

denik20:10:40

since ssh does not exit on its own anything i try with process ends up blocking and not printing

borkdude20:10:19

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

borkdude20:10:10

Try this:

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

denik20:10:16

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

borkdude20:10:39

The same expression should work in the REPL

denik20:10:33

just tried. perfect. thanks so much @U04V15CAJ

borkdude20:10:38

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

denik20:10:02

if I chain processes will those stay ssh’d?

denik20:10:12

in the same expression

borkdude20:10:32

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

borkdude20:10:16

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

borkdude20:10:12

Like this:

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

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

nil

borkdude20:10:24

so I'm writing ls first and then whoami

🙏 1
denik20:10:31

thanks again and did something that was long overdue

borkdude20:10:56

Thanks a lot :)

denik20:10:03

thank you!

vadyalex20:10:14

I went down a rabbit hole exploring babashka pods.. bb <> pod process communication architecture using bencode ., bencode protocol and it usage outside of Torrent protocol.. nREPL ... Because of my limited experience with bencode I am strangling to understand why bb uses bencode even though payload is edn/`json` ?

borkdude20:10:44

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

vadyalex20:10:43

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