bb.edn / task runner update:
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
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
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?
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?
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
Yeah maybe something to add later after some user feedback. Maybe it’s not needed (yet)
right
but might also be good to get this right before initial release
True
Are you seeing this also as a boot / lein replacement ?
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
Cool, nice
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
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
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.
So I think having a purely additive classpath works best.
And do dep resolution only once with aliases from both clean and foobar
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.
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 taskI’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
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
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]}}}
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]}}}
but this kind of duplicates things. Maybe as a convention, a task opts into the alias of the same name
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 ;)
haha always good to try to be lazy. I don’t think you are btw 😉
Maybe:
{:tasks {:http-server {:task/type :main
:task/deps {:extra-paths ["/Users/borkdude/Dropbox/bb_scripts"]}
:main http-server.main}}}
so :task/deps
can have the same thing as an alias perhaps
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?
but this could lead to a lot of duplication of you want to repeat the {:extra-paths ...}
thing for every global task
(my slack is laggy)
(same here)
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
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)
ok, cool will do that
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”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 🙂Thanks, you can post feedback here: https://github.com/babashka/babashka/discussions/757
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 exampleI’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?
ah nevermind found one https://github.com/babashka/babashka/blob/bb.edn/test-resources/bb.edn
:paths
only influences the classpath
this is just from deps.edn
so the latter I would write as :task/type :main
and then expose your http server under a -main
function
and then :main http-server.main
or :main http-server/start
or something if you want to use a fully qualified function name different from -main
@borkdude what do you think about "global" bb,.edn -
~/.config/bb/bb.edn
or
'~/.bb/bb/edn
that is being considered, along with global tasks, so you can do bb :http-server
anywhere on your system
(see the discussion with jeroen in the thread above)