Fork me on GitHub

Cool new library for CLI arg parsing. It works with babashka if you include spartan.spec:


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

馃憤 9

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


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鈥檓 in the dir parent/child and I invoke bb it would use the bb.edn of the parent dir (when the child dir doesn鈥檛 have a bb.edn )


I think this would be helpful in bigger projects, but I鈥檓 curious if i鈥檓 alone in this


I think this can be conflicting with relative :paths so I would say let's avoid it for now

馃憤 3

Maybe having a parent bb.edn and a local bb.edn can be useful in a mono-repo


There is also the :init thing to think about :thinking_face:


yeah I can imagine things start to get complicated


I think local :init would just override the global :init but if you would invoke a global task, that would depend on the global :init then... arg

馃槄 3

I鈥檓 experimenting with tools.deps in a monorepo indeed. I鈥檓 having 10+ local libraries now. I think the potential is great, but it is a bit off-putting if you have to copy the same files to get standard tasks. So for this it would be helpful. I鈥檓 not sure yet where this will go. Maybe I鈥檒l find other ways to deal with this


It's already possible to include libraries in babashka so maybe that's the way to do it.


yeah exactly I鈥檓 still figuring out what I really need


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

pithyless10:05:47 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


Just to avoid confusion, does bb tasks always list the bb run <something> version?


BTW, I don't like this kinda of "trying to do the right thing depending of the context", I was bitten more than one time by people automatizing scripts and people not realizing that a simple PR adding a new parameters ended up shadowing the old usage of the program


And everything breaking horrible afterwards


But this is my 2c


In bb new features will never shadow old usage


So it won鈥檛 break users. Users will simply not have access to the new feature if their usage shadows it, which is not breaking since they didn鈥檛 use the new feature yet.

馃憤 2

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

馃憤 3

(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.

馃憤 3

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 馃槃

馃帀 3

Ooh, thank you!

Jakub Hol媒 (HolyJak)15:05:52

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

馃憤 3

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

Jakub Hol媒 (HolyJak)15:05:53

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

馃憦 2

It's a dirty job but someone has to do it 馃檪