This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-12
Channels
- # announcements (1)
- # babashka (79)
- # beginners (165)
- # calva (29)
- # cider (20)
- # clara (3)
- # cljdoc (1)
- # cljs-dev (52)
- # clojure (42)
- # clojure-chicago (5)
- # clojure-europe (48)
- # clojure-germany (1)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-spec (10)
- # clojure-uk (19)
- # clojurescript (50)
- # clojureverse-ops (5)
- # conjure (8)
- # datomic (16)
- # depstar (2)
- # events (1)
- # figwheel-main (23)
- # fulcro (26)
- # girouette (41)
- # graalvm (9)
- # heroku (3)
- # honeysql (10)
- # jackdaw (20)
- # lambdaisland (6)
- # lein-figwheel (1)
- # lsp (34)
- # malli (7)
- # meander (3)
- # music (1)
- # off-topic (14)
- # polylith (7)
- # re-frame (14)
- # reitit (8)
- # reveal (15)
- # ring (3)
- # schema (1)
- # sci (15)
- # shadow-cljs (42)
- # spacemacs (1)
- # startup-in-a-month (12)
- # tools-deps (59)
- # vim (1)
- # xtdb (27)
does :init
still works on babashka tasks? I’m trying to use but seems like it’s being ignored
@wilkerlucio sorry, it broke. I will fix and make a new release
@wilkerlucio I guess one can also write a hidden -init
task and then :depends
on that :)
@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]}}}
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).
also with init I can have a more clean to read tasks (without having to make all of them maps with depends)
More real life example: https://github.com/borkdude/mach/blob/bb-run/examples/app/bb.edn
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)}}}}
or:
{:tasks {:aux {target-dir "target"}
uberjar {:depends [target]
:task (fs/delete-tree target)}}}
or:
{:tasks {:private [target-dir]
target-dir "target"
uberjar {:depends [target]
:task (fs/delete-tree target)}}}
It's more natural to think of .
as that means hidden in both unix (and funnily enough yml) land
yeah, but according to the reader docs that character is reserved by clojure for symbols, so I won't do that
also -
in beginning is idiomatic for Clojure, so I’ll keep that 👍
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.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
Wow, that’s weird. With Measure-Command
it runs in 2-3ms, but just at the command prompt it’s clearly slower.
According to Task Manager I’m only about 50% memory, and everything else seems pretty snappy. Running echo 'hi'
from Powershell is instantaneous.
Yeah, it’s a corporate machine so the virus scanner is omnipresent. Maybe Measure-Command
somehow avoids the virus scanner
It’s not a showstopper for me. Just want to remove any possible objections to using Babashka 🙂
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
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.
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).
At work I can deprecate some bb script perhaps, that I wrote to simultaneously load processes for development: <uploading screenshot below>
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
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)}}}
Yeah I also tried with tasks2
but that didn’t help. I’ll try your init suggestion! Thanks!
It only works when you use resolve
as these names are only valid in the next top level expression, this is how clojure works :/
so adding explicit an :require
option should take care of this by moving the requires on top
ah yeah, resolve. Thanks! Forgot about that. I tried with eval, but that didn’t work. (eval '(tasks/midje))
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
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 ]]
Makes sense! Thanks
@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.Looks very good! Thank you
Is the full namespace of clojure.spec.alpha provided in the feature/spec-alpha? Reason why I can’t resolve (s/keys)
?
@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
ah ok.. tks
if ever 🙂
@garyberger Meanwhile you can possibly also use https://github.com/borkdude/spartan.spec
@borkdude what was again that trick you told me the other day to prevent babashka from stopping? do you remember?
I remember was about deferring something at the end, but I can’t remember the details
was it @(promise)
?
oh heh 😛
yes! thanks 🙂