Clojurians Log v2

@borkdude how can I point to remote scripts? This is what I have now:

{:paths ["<https://github.com/FieryCod/holy-lambda/tree/master/modules/holy-lambda-babashka-tasks/script/>"]

 :holy-lambda/options {:build-tool    :lein ;; or :deps
                       :runtime       {:name :babashka} ;; Possible runtime :babashka, :native, :java
                       }

 :infrastructure {:bucket-prefix  "prefix"
                  :bucket-name    "bucket"
                  :region         "region"}

 :tasks {:requires                ([holy-lambda.tasks])

         docker:build:ee          holy-lambda.tasks/docker-build-ee
         sync:update              holy-lambda.tasks/sync:update
         version                  holy-lambda.tasks/version
         doctor                   holy-lambda.tasks/doctor
         purge                    holy-lambda.tasks/purge}}

@karol.wojcik Where did you get the idea that "remote scripts" were supported :-D?

You can make a git library from it and point to it in :deps same as with deps.edn

😄

Oh, I misinterpreted that. I thought you meant: is it ok if I share the link to a library on github in this channel :)

Will try the deps.edn approach then 😄

@karol.wojcik What was the other bug you found?

{:paths ["script"
         ;; "<https://github.com/FieryCod/holy-lambda/tree/master/modules/holy-lambda-babashka-tasks/script/>"
         ]

 :holy-lambda/options {:build-tool    :lein ;; or :deps
                       :runtime       {:name :babashka} ;; Possible runtime :babashka, :native, :java
                       }

 :infrastructure {:bucket-prefix  "prefix"
                  :bucket-name    "bucket"
                  :region         "region"}

 :tasks {:requires                ([holy-lambda.tasks :as tasks])

         docker:build:ee          tasks/docker-build-ee &lt;-- needs fully qualified symbol otherwise it does not work.
         sync:update              tasks/sync:update
         version                  tasks/version
         doctor                   tasks/doctor
         purge                    tasks/purge
         }}

Using :as does not work in :requires when script is from :paths

oh cool, I'll fix that

Fixed on master

@karol.wojcik Was this bug only related to bb tasks docstrings or also to execution of these tasks?

I guess also to execution, will also fix that

Fixed on master

Both AFAIK

I am contemplating letting tasks not print the return value by default (like scripts always have done so far which might have been a mistake, but accidentally happened) But still it is convenient to view the result of a (helper) task to debug.

So maybe bb run --prn foo could be used to explicitly print and bb foo doesn't print

Or maybe it should be a property of a task if it will print or not?

{:tasks {foo {:print true :task (System/getenv "FOOBAR")}}}

babashka 0.3.6 released See CHANGELOG.md: https://github.com/babashka/babashka/blob/master/CHANGELOG.md

@mike1452 shell now supports :continue true to ignore the exit code (so it won't exit bb in that case)

Also tasks do not print their return value anymore (unless explicitly done or using the run --prn command line opts)

It's also possible to use the return value of shell and clojure now

And there is some logging around task names and shell/clojure arguments when setting :log-level :info in the task(s)

There is also a :min-bb-version to print a warning in case people use an older one (top level in bb.edn)

It's all documented here: https://book.babashka.org/#_bb_edn and here: https://github.com/babashka/babashka/issues/778

Please do try out your bb with {:tasks {:log-level :info ...}} to see if it's useful

@borkdude cool! I'll check new version and change my templates. You are doing awesome work!

@borkdude can I pass my own decoration fn for log-level?

no not yet. I think I might revise the entire log thing based on some feedback

to experiment: there is babashka.tasks/*-task-name* , babashka.tasks/-log-info and babashka.tasks/-log-error and you can probably roll your own thing with this

all implementation details which will change, but feel free to play around and provide feedback

Did I ask how to run babashka tasks like in makefile? make clean pack deploy? 😄

Will experiment with it

@karol.wojcik bb doesn't yet have a way to do this, other than bb clean && bb pack && bb deploy or do that in a task using three shell calls

I am considering doing something like bb run clean, pack, deploy like comma separated values like lein do has

so you can still pass args to the tasks

Exactly that would work, since I'm parsing the arguments for holy-lambda.

Made an issue: https://github.com/babashka/babashka/issues/804 But still I'm not yet certain how much needed this is, since it's not much more typing than just using && and like @jeroenvandijk has said: lein do is also about startup time of the JVM, a problem that bb doesn't have.

This might also conflict with passing JSON or EDN values on the command line. Not sure how well lein do copes with that.

Does it look cool?

There is one thing I would love to see. Ordering of bb tasks

:tasks {:requires                ([holy-lambda.tasks])
         :log-level               :info

         docker:build:ee          holy-lambda.tasks/docker-build-ee
         bucket:create            holy-lambda.tasks/create-bucket
         bucket:remove            holy-lambda.tasks/remove-bucket
         stack:destroy            holy-lambda.tasks/stack-destroy
         stack:deploy             holy-lambda.tasks/stack-deploy
         version                  holy-lambda.tasks/version
         doctor                   holy-lambda.tasks/doctor
         purge                    holy-lambda.tasks/purge
         logs                     holy-lambda.tasks/logs}}

Maybe it could be taken from the metadata of the function

Hmm, we could support sorting if we supported the notation:

{:tasks
  [[:requires ...]
   [:log-level ...]
   [docker-build foobar]]
}

but because it's a map, we cannot preserve the order

Are you interested in preserving the order or you just don't care?

I think it would be nice, we could support a vector notation like this:

{:tasks [
  :requires ...
  :log-level ...
   docker-build foobar
]
}

Yep. Btw how can I overwrite babashka.tasks/log-info? I'm not familiar with sci.

Same as in clojure, just use def. The name is -log-info (indicating that it is an impl detail)

oh you want to intern it into the babashka.tasks namespace

Yep. tried to use alter-var-root but it doesn't work.

it should

show me what you did then

(alter-var-root #'babashka.tasks/-log-info
                  (fn [& strs]
                    (println "xx" strs)))

~/Workspace/Work/holy-lambda/modules/holy-lambda-babashka-tasks master*
❯ bb doctor
xx (#object[babashka.impl.tasks$log_info 0x38037185 babashka.impl.tasks$log_info@38037185])
----- Error --------------------------------------------------------------------
Type:     java.lang.NullPointerException

you need to pass a function which returns a function to alter-var-root, same as in clojure ;)

@karol.wojcik Use constantly around the function, for example

afk for dinner now

Ahh you're right. Thanks!

Any chance we could add https://github.com/clj-commons/ordered to babashka? Then perhaps we could use the #ordered/map literal when defining tasks in bb.edn ? Having the ordered literal around could be useful in a couple of places when working with bb in general :]

@pithyless afaik that is already available:

bb -e "(use 'flatland.ordered.map)"

but you're right, that could be a nice solution

@dharrigan btw your suggestion of having the argument order (copy-into dir f1) has been suggested by other people as well + the suggestion of making it varargs:

(copy-into dir f1 f2 f3)

(one of the difficulties in that case is: where to put the options)

oh, I didn't realize the literal syntax is #ordered/map ([:a 1] [:d 4] [:b 7]) ; I was hoping it still looked mostly like a map

ah crap, yeah, I guess it can't be a map literal because by the time the lib sees it the order has already been messed up

so we might as well go with [:a 1 :b 2 :c 3] as the alternative notation?

and then use apply hash-map for map semantics, but use the order for printing

uhh, I'd vote for [[:a 1] [:b 2]] (I guess that's the compromise malli ordered-maps also settled on)

{:tasks [[:requires ([babashka.fs :as fs])]
         [ls (shell "ls")]
         [clear {:doc "blabla"
                 :task (shell "rm -rf targt")}]]}

{:tasks [:requires ([babashka.fs :as fs])
         ls (shell "ls")
         clear {:doc "blabla"
                :task (shell "rm -rf targt")}]}

yeah ok, the first one might be more "idiomatic", although (require '[foo :as x :refer [1 2 3]) is similar to the first one

as in, it squashes basically a map in a vector

I'm still wondering if it's worth it; the map syntax is nice and perhaps the order of task printing is a separate concern? i.e. it can be a separate thing in bb.edn (either a vector or even a function that sorts -- or even groups -- tasks by some logic)?

alternatively, we could support something like a :print-order function or literal, but this might be duplication of names

hah

yeah, you are right, I was also thinking a function which can sort the tasks topologically, so you get the "main" tasks first for example

having a :print-order function or literal sounds like the better approach; I'm wondering if the default implementation couldn't even be something crazy like slurping in bb.edn and generating the list of tasks by parsing the edn "by hand"?

I would like to hide as much of tasks implementation from the user as it is possible. If I could hook to some kind of babashka.tasks/print-order function from tasks impl I would be most satisfied.

I think babashka could cheat

by determining the position of the first key in the map and then read the tokens one by one until it encounters }

Seems like a hack, but I like it

that's kind of what I had in mind

it's actually pretty easy since edamame can read the begin and end position of the tasks map, then just strip all of that stuff away, read it as a vector (by wrapping) and done

I forgot you had the power of edamame to wield freely

I don't use it currently to read the edn (I want to make sure the .edn is compatible with the regular EDN reader) but for the printing of the tasks, I will 👿

Maybe two blank lines means one empty line will be printed in the output as well, for some grouping?

Heck, I could even use rewrite-clj for this since it’s bundled with bb now

The printing of namespaces conform their occurrence should work now on master (binary available in #babashka-circleci-builds)