Fork me on GitHub
#babashka
<
2021-04-12
>
wilkerlucio06:04:13

does :init still works on babashka tasks? I’m trying to use but seems like it’s being ignored

borkdude07:04:39

@wilkerlucio sorry, it broke. I will fix and make a new release

borkdude07:04:49

(and write a test)

borkdude07:04:34

@wilkerlucio I guess one can also write a hidden -init task and then :depends on that :)

borkdude09:04:58

@wilkerlucio I just released 0.3.4. I'm considering to deprecate :init because you can do it all with :depends and this also leads to better local reasoning about a task perhaps.

{:tasks {-target-dir "target"
         -target {:depends [-target-dir]
                  :task (fs/create-dirs -target-dir)}
         -jar-file {:depends [-target]
                    :task "target/foo.jar"}

         jar {:depends [-target -jar-file]
              :task (when (fs/modified-since -jar-file
                                             (fs/glob "src" "**.clj"))
                      (spit -jar-file "test")
                      (println "made jar!"))}
         uberjar {:depends [jar]
                  :task (println "creating uberjar!")}
         clean {:depends [-target-dir]
                :task (fs/delete-tree -target-dir)}
         uberjar:clean {:depends [clean uberjar]}}}

👍 1
wilkerlucio14:04:40

I understand it can be done that way, but it also is way more poluted to look at that than was with init, I think would be nice to have both options (:init is more convenient if I dont care much about extra processing, and just want to add stuff to everything).

wilkerlucio14:04:16

also with init I can have a more clean to read tasks (without having to make all of them maps with depends)

borkdude14:04:45

ok. understood. :init is still supported :)

🙂 2
borkdude14:04:34

and back in 0.3.4 btw

borkdude14:04:39

(it was lost by accident)

dharrigan12:04:29

Would . also work instead of -?

dharrigan12:04:35

i.e., .target

borkdude12:04:56

any other character would work, but I'm not sure if .foo is a valid name in clojure, since dot is interop-related: > Symbols beginning or ending with '.' are reserved by Clojure. https://clojure.org/reference/reader Open to other ideas/characters though. We could also do:

{:tasks {:private {target-dir "target"}
         :public {clean {:depends [target]
                         :task (fs/delete-tree target)}}}}

borkdude12:04:55

or:

{:tasks {:aux {target-dir "target"}
         uberjar {:depends [target]
                  :task (fs/delete-tree target)}}}

borkdude13:04:51

or:

{:tasks {:private [target-dir]
         target-dir "target"
         uberjar {:depends [target]
                  :task (fs/delete-tree target)}}}

borkdude13:04:34

but so far -target-dir doesn't seem like an unreasonable thing perhaps

dharrigan13:04:05

It's more natural to think of . as that means hidden in both unix (and funnily enough yml) land

dharrigan13:04:41

so a hidden task, like a hidden file

borkdude13:04:46

yeah, but according to the reader docs that character is reserved by clojure for symbols, so I won't do that

borkdude13:04:50

alternatives: _ or *, but so far, - is the best one imo

wilkerlucio15:04:35

also - in beginning is idiomatic for Clojure, so I’ll keep that 👍

dharrigan13:04:03

agreed, best of the bunch

jkrasnay14:04:11

Any thoughts on why bb might be slow to start up on Windows? I have this little bb.edn script:

{:tasks {hello (println "hi!")}}
On my MacBook Pro it runs pretty consistently in about 30ms, but on Windows it usually takes about 2 seconds, sometimes up to 5s and sometimes as low as 800ms, but always much slower.

borkdude14:04:54

@U0DTSCAUU

PS C:\Temp> bb version
babashka v0.3.4
PS C:\Temp> bb tasks
The following tasks are available:

hello
PS C:\Temp> Measure-Command { 'bb hello' }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 0
Ticks             : 9103
TotalDays         : 1.05358796296296E-08
TotalHours        : 2.52861111111111E-07
TotalMinutes      : 1.51716666666667E-05
TotalSeconds      : 0.0009103
TotalMilliseconds : 0.9103

borkdude14:04:20

cannot reproduce this

jkrasnay14:04:08

Wow, that’s weird. With Measure-Command it runs in 2-3ms, but just at the command prompt it’s clearly slower.

borkdude14:04:36

Maybe some virus scanner?

borkdude14:04:45

Is your system memory contrained?

borkdude14:04:28

How about cmd.exe?

jkrasnay14:04:35

According to Task Manager I’m only about 50% memory, and everything else seems pretty snappy. Running echo 'hi' from Powershell is instantaneous.

borkdude14:04:00

again, are you using a virus scanner?

jkrasnay14:04:02

Getting the same slow response running under cmd and also under Git bash.

jkrasnay14:04:30

Yeah, it’s a corporate machine so the virus scanner is omnipresent. Maybe Measure-Command somehow avoids the virus scanner

borkdude14:04:56

maybe you can put bb in the allow list of the virus scanner or something?

jkrasnay14:04:25

Oh, that’s a good idea. I’ll look into that.

jkrasnay14:04:54

It’s not a showstopper for me. Just want to remove any possible objections to using Babashka 🙂

borkdude14:04:00

And now that it even supports a shebang in .bat scripts, I can't see why the entire corporate Windows world isn't jumping on it

😂 1
jkrasnay14:04:36

I know, right? So far the fact that it’s a single .exe that I can install without admin privileges makes it an easy sell.

jkrasnay14:04:36

(native Windows, not WSL)

borkdude14:04:44

no idea, but I will try

borkdude15:04:18

At work I can deprecate some bb script perhaps, that I wrote to simultaneously load processes for development: <uploading screenshot below>

borkdude15:04:45

So I can just kick off bb dev and start working

jeroenvandijk16:04:33

Should it be possible to require a namespace in the tasks? I have a function that I can call directly (`bb -m tasks/midje`), but not from a task when I do

{:paths
 ["bb-scripts"]

 :tasks {clean {:doc "Clean target dir"
                :task (shell "rm -rf target")}
         midje {:doc "Run midje tests"
                :depends [clean]
                :task (do (require 'tasks)
                          (tasks/midje))}}
This gives me: Could not resolve symbol: tasks/midje

borkdude16:04:43

tasks is already an alias for babashka.tasks

borkdude16:04:05

This could work:

{:paths ["src"]
 :tasks {:init (ns my-tasks
                 (:require [babashka.tasks :refer [shell]]
                           [tasks :as t]))
         clean {:doc "Clean target dir"
                :task (shell "rm -rf target")}
         midje {:doc "Run midje tests"
                :depends [clean]
                :task (t/midje)}}}

borkdude16:04:51

Maybe a task should have a special :require option for this

👍 1
borkdude16:04:28

so those can be executed before the task code is executed

borkdude16:04:58

I think I'll remove the tasks alias perhaps because this can get confusing

👍 1
jeroenvandijk16:04:40

Yeah I also tried with tasks2 but that didn’t help. I’ll try your init suggestion! Thanks!

borkdude16:04:21

It only works when you use resolve as these names are only valid in the next top level expression, this is how clojure works :/

borkdude16:04:48

so adding explicit an :require option should take care of this by moving the requires on top

👍 1
jeroenvandijk16:04:05

ah yeah, resolve. Thanks! Forgot about that. I tried with eval, but that didn’t work. (eval '(tasks/midje))

jeroenvandijk16:04:17

Don’t work

:task (do (require 'tasks)
          ((resolve 'tasks/midje)))
          
:task (do (require 'tasks)
          (eval '(tasks/midje)))}
Works
:task (do (require '[tasks :as t])
          ((resolve 't/midje)))
          
:task (do (require '[tasks :as t])
          (eval '(t/midje)))}
So you were right; it was not working because of the already existing alias tasks

borkdude16:04:34

You can also use (ns-unalias *ns* 'tasks) perhaps

👍 1
borkdude17:04:01

Hmm, it seems ns-unalias isn't available in bb. A good reason to add it. Being explicit about requires will also help us prevent bb alias conflicts, because I can automatically unlias the existing ones and replace them with the user's ones.

{:doc ...
 :require [[foo :as fs] [:bar :as ]]

jeroenvandijk17:04:24

Makes sense! Thanks

borkdude21:04:32

@U0FT7SRLP In the next iteration of bb your task will become:

{:paths ["src"]
 :tasks {clean {:doc "Clean target dir"
                :task (shell "rm -rf target")}
         midje {:doc "Run midje tests"
                :depends [clean]
                :requires ([tasks])
                :task (tasks/midje)}}}
So :requires is a list of libspecs. Also supported on the top-level. There will be no more automatic aliases. clojure and shell will be there, but can be overridden by the user without errors.

borkdude21:04:39

Also just {:doc "run midje" :task tasks/midje} is supported

borkdude21:04:51

this will automatically call the function with *command-line-args*

jeroenvandijk07:04:01

Looks very good! Thank you

Gary Berger16:04:15

Is the full namespace of clojure.spec.alpha provided in the feature/spec-alpha? Reason why I can’t resolve (s/keys)?

borkdude16:04:42

@garyberger Probably not the full namespace, it's more or less a proof of concept. I do have it included in grasp: https://github.com/borkdude/grasp/blob/master/src/grasp/native.clj

borkdude16:04:59

But feel free to add stuff to it

borkdude16:04:01

I want to add spec once it's out of alpha

wilkerlucio17:04:08

@borkdude what was again that trick you told me the other day to prevent babashka from stopping? do you remember?

wilkerlucio17:04:45

I remember was about deferring something at the end, but I can’t remember the details

Darin Douglass17:04:58

was it @(promise)?

wilkerlucio17:04:03

yes! thanks 🙂