Cool new library for CLI arg parsing. It works with babashka if you include spartan.spec: https://github.com/clj-clapps/clj-clapps/issues/1

Should babashka have global tasks in <home>/.config/.babashka/bb.edn?

I feel that the global tasks should be disjunct from the project specific tasks. I.e. you can't have a dependency in a project specific task on a global task or vice versa.

So when you invoke bb foo and foo is in the local bb.edn, the global tasks will be ignored

And vice versa, when you invoke bb global-foo, the local bb.edn will be ignored

^ @orestis

I agree with local vs global. What do you think about looking up bb.edn files in parent dirs? E.g. when I have parent/bb.edn and I’m in the dir parent/child and I invoke bb it would use the bb.edn of the parent dir (when the child dir doesn’t have a bb.edn )

I consider bb.edn a great entrypoint into a project, so I imagine there would be one for a monorepo (and using arguments / subcommands when needing to scope to certain submodules). Similarly, I'm not yet convinced about having global tasks, since (a) it would now be some external thing that is obviously not specific to a project entry-point, (b) any common logic between projects can (and probably should) be moved to clj code that can be imported by any bb.edn, (c) it complicates things like understanding some hidden dependency between project tasks and global tasks (e.g. even if the default behavior is "run local task if found" I would be very surprised if I expected to run my global task when typing bb some-funky-name-that-hopefully-no-project-uses

deps.tools has exactly the same problems with the confusion related to -Srepro and I think my concerns could be alleviated if babashka had a similar mode (but probably reversed the default). So perhaps bb foo will always run local foo (or fail) and something explicit like bb global foo will always run the global task (or fail)

hmm bb run --global foo could work

but I agree, the need for a global thing is maybe far fetched

unless you have certain tools in your global deps.edn that you would like to have easy access to

but then bb run --global foo is already too much to type

if it's just a question of typing less, bb will never compete with the ubiquity and flexibility of a shell's alias ;]

yeah, I agree, but it would be cool to have a cross platform way of aliasing, regardless of your shell

so you could share your config on any computer

e.g you have the clj-new alias in your deps.edn. Instead of typing clojure -M:new ... you could type bb new ..., I guess that doesn't add very much, I agree with this.

and people who tend to be on *nix don't care about cross platform with Windows anyway

I've also considered a global "script" dir for bb, I think that might be a better fit. e.g. ~/.config/babashka/scripts where it will look for files as a fallback and you could also install useful scripts from other places.

bb install com.github/foobar/webserver webserver
bb webserver

yeah, one of the things that bugs me the most is the potential for name conflicts by using the implicit bb run foo vs bb foo - this problem would probably be exacerbated if you allow essentially supporting some arbitrary BB_SCRIPTS_PATH . It's a neat idea, but I'd feel better if it was explicit ala bb run --global webserver or eg. bb cmd webserver . Maybe even steal git's idea and just take advantage of the default PATH? Any executable named bb-webserver would immediately be a babashka package ala bb cmd webserver

But this is all starting to sound pie-in-the-sky... I'm just happy we now have bb tasks for projects 😉

We can still revert to explicit bb run foo and remove bb foo

The reason I went with bb foo is that it's more similar to make foo

You'd have my sword, but it may be a very small fellowship. 😄

bb run foo also works btw

yeah, I'm aware; just if you allow bb foo and it becomes popular, you will never be able to take it back. :]

I kind of assumed that ship had sailed already

well, I'm close to an announcement of a "stable" bb tasks. so far I have tried to emphasize that this is still work in progress https://github.com/babashka/babashka/issues/778

also the bb foo is inspired by lein foo where foo is a lein alias

I think it's ok to allow it, while also offering escape hatches in case of conflicts

The escape hatches:

Task: bb run foo
File: bb ./foo or bb -f foo
Subcommand: bb --foo

(file always has precedence, it's FILE > TASK> SUBCOMMAND)

This brings me back to my original point - I'm not a fan, but it's borderline aesthetics and very small cognitive dissonance; and not a hill I plan to fight on; but if we start talking about global tasks that are outside of the existing project entrypoint that may also auto-resolve themselves, the chance for surprises and name collisions increases.

As for resolving names, I don't think it will be a big issue, like with clojure: local wins over global. Global tasks bring other complexities I'm more worried about. Thanks for reinforcing that worry, I will probably not implement it. Like you said, a shell alias (or global script) is probably the better answer to global tasks.

Having suggested something like global tasks, I agree that having them is not that important, since you can point bb to any bb.edn file regardless of your current directory.

Thanks for the idea of having global clj code that then your task can reference.

BTW I may not be using babashka proper but I'm loving the utility libraries like babashka.fs 🙂

Wait, how was I not sponsoring you before? Sponsoring now via our open source support project which I made up this year 😄

Ooh, thank you!

The httpkit server only supports http so if I need https then I have to use some proxy or something, right?

you'd have to check the httpkit docs for this, don't know. #http-kit might know

I think I've read something like using nginx as a reverse proxy to do this

In case you run on AWS, the load balancer can do this for you

Now, I'm trying to make CLI tool for OIDC end-user login :)