Fork me on GitHub
#babashka
<
2021-03-23
>
borkdude10:03:48

bb.edn / task runner update:

❤️ 14
jeroenvandijk10:03:52

Nice! Not sure if it makes a difference for boot time, but maybe useful for isolation, are you thinking of having the :deps key per task?

borkdude10:03:18

yeah, I'm still thinking about this. probably just support :aliases like deps.edn and then in a task you can have :task/aliases [:foo :bar] to include deps from those aliases?

borkdude10:03:23

then everything works like expected, e.g. extra-deps, replace-deps. the only problem is, what happens when you combine multiple tasks? probably all of the aliases should be combined then as well

jeroenvandijk10:03:16

Yeah maybe something to add later after some user feedback. Maybe it’s not needed (yet)

borkdude10:03:36

but might also be good to get this right before initial release

jeroenvandijk10:03:58

Are you seeing this also as a boot / lein replacement ?

borkdude10:03:05

kind of a light weight replacement for make (have an overview of things you can invoke in a project) you can read the "problem statement" here: https://github.com/babashka/babashka/issues/756

jeroenvandijk10:03:30

Regarding, the combining of multiple tasks. In my experience over time a project.clj or deps.edn gets really cluttered of dependencies that might or might not be needed anymore. Having deps per task might allow for keeping it cleaner via isolation. Also when you want to extract / update something it will be beneficial

jeroenvandijk10:03:00

I guess this also depends if it is possible to have two different versions of the same library on babashka’s path. That would be a requirement for that to work I’m guessing

borkdude10:03:37

if you want to combine multiple tasks like bb :clean:foobar and clean uses lib1 v1 and foobar uses lib1 v2, then I'm not sure what should happen. Then we should unload certain things but that is error prone probably, since there may be references to these things by used-defined functions.

borkdude10:03:49

So I think having a purely additive classpath works best.

borkdude10:03:05

And do dep resolution only once with aliases from both clean and foobar

borkdude10:03:35

So one example where this is really needed is in the case of global tasks in ~/.babashka/bb.edn, e.g. :http-server. Then we want to include some script which runs an http server we don't always want to have that on our classpath all the time.

borkdude10:03:49

So I was thinking:

:tasks {:http-server {:task/type :main :main cool.http-server :aliases [:http-server]}}
:aliases {:extra-deps {....}}
but maybe in this case it would have been nicer to have `:extra-deps directly inside the task

jeroenvandijk11:03:21

I’m not sure what the reasoning was behind :extra-deps in tools.deps But in my naive opinion having the deps in the task itself is nicer

borkdude11:03:51

The idea in deps.edn is that you can compose the base deps with more deps. But deps.edn also has :replace-deps which is used for more isolated tasks

borkdude11:03:26

So e.g. in ~/.babashka/bb.edn you could have:

{:aliases {:http-server {:extra-paths ["/Users/borkdude/Dropbox/bb_scripts"]}}
 :tasks {:http-server {:task/type :main
                       :main http-server.main
                       :aliases [:http-server]}}}

borkdude11:03:26

but this kind of duplicates things. Maybe as a convention, a task opts into the alias of the same name

borkdude11:03:08

I agree that it would be nicer to have this directly in the tasks, but this requires somewhat more processing and I thought I could be lazy ;)

jeroenvandijk11:03:40

haha always good to try to be lazy. I don’t think you are btw 😉

borkdude11:03:56

Maybe:

{:tasks {:http-server {:task/type :main
                       :task/deps {:extra-paths ["/Users/borkdude/Dropbox/bb_scripts"]}
                       :main http-server.main}}}

borkdude11:03:09

so :task/deps can have the same thing as an alias perhaps

👍 1
jeroenvandijk11:03:30

another consideration might be to think of how much overlap in deps there is between tasks. Maybe less than in normal deps.edn usage. So less gain in composing?

borkdude11:03:11

but this could lead to a lot of duplication of you want to repeat the {:extra-paths ...} thing for every global task

borkdude11:03:18

(my slack is laggy)

jeroenvandijk11:03:44

What if you don’t implement it yet and we have the minimal version for feedback under beta users? You can evaluate how our bb.edn looks and you can decide based on that? Just a suggestion of course

borkdude11:03:29

yeah, that might be good, but I think for global tasks like bb :http-server (instead of python -m http.server) it already makes sense to have a good story for this you can test the beta using binaries from #babashka-circleci-builds already (bb.edn branch)

jeroenvandijk11:03:50

ok, cool will do that

jeroenvandijk11:03:46

Where shall I post silly user feedback 😅? E.g. I thought it wasn’t working because I was using an unknown task

bb :taadf
File does not exist: :taadf
because of the colon I was expecting something like “Task does not exist”

jeroenvandijk11:03:30

Another here

➜  ~ bb :tasks
The following tasks are available:

:foo nil

Run bb :help <task> to view help of a specific task.
➜  ~ bb :foo
No such task:
That’s what you get when you use a vector instead of a map 🙈
{:tasks {:foo [:task/type :babashka
               :task/description "adf"
               :task/args [-e (println "Hi")]]}}  
With a map it works 🙂

jeroenvandijk12:03:39

Is :paths already working? If so, I don’t think I understand how it works. Am i doing something wrong below?

{:paths ["/Users/jeroen/bin/bb-scripts"]
 :tasks 
 {:http-server-ok {:task/type :babashka
                    :task/description "HTTP server"
                    :task/args ["/Users/jeroen/bin/bb-scripts/http-server"]}      
                               
  :http-server-fail {:task/type :babashka
                       :task/description "HTTP server"
                       :task/args ["http-server"]}       
                     
}}
:http-server-ok works in the above example

jeroenvandijk12:03:31

I’m guessing I need to put clj / bb files in the path and use :task/type :main . I don’t have it working yet. Do you have an example project somewhere?

borkdude12:03:27

:paths only influences the classpath

borkdude12:03:50

this is just from deps.edn

borkdude12:03:37

so the latter I would write as :task/type :main and then expose your http server under a -main function

borkdude12:03:45

and then :main http-server.main

borkdude12:03:17

or :main http-server/start or something if you want to use a fully qualified function name different from -main

👍 1
richiardiandrea17:03:24

I like this, as a data point, I would love something like this for moving the scripts aliases (say the alias for :carve that we use) from my deps.edn to it. I would leave only dependency/per profile information in deps.edn

borkdude17:03:59

Thanks for the feedback. The discussion here: https://github.com/babashka/babashka/discussions/757#discussioncomment-540032 shifted a bit towards: less DSL, more normal functions. This is explored here now: https://github.com/babashka/babashka/discussions/765

👍 1
maxp12:03:21

@borkdude what do you think about "global" bb,.edn - ~/.config/bb/bb.edn or '~/.bb/bb/edn

borkdude12:03:14

that is being considered, along with global tasks, so you can do bb :http-server anywhere on your system

😎 4
borkdude12:03:43

(see the discussion with jeroen in the thread above)