This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # babashka (56)
- # beginners (89)
- # cider (4)
- # clj-kondo (25)
- # cljsrn (28)
- # clojars (30)
- # clojure (21)
- # clojure-australia (16)
- # clojure-europe (43)
- # clojure-italy (14)
- # clojure-nl (2)
- # clojure-spec (11)
- # clojure-sweden (7)
- # clojure-uk (8)
- # clojurescript (37)
- # cursive (4)
- # datomic (42)
- # defnpodcast (2)
- # dirac (1)
- # events (4)
- # fulcro (3)
- # graalvm (43)
- # graphql (6)
- # helix (1)
- # jackdaw (12)
- # jobs (3)
- # lambdaisland (8)
- # malli (11)
- # off-topic (82)
- # pathom (3)
- # re-frame (4)
- # reagent (2)
- # reitit (4)
- # remote-jobs (1)
- # shadow-cljs (27)
- # vim (20)
Cool new library for CLI arg parsing. It works with babashka if you include
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
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
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)
unless you have certain tools in your global
deps.edn that you would like to have easy access to
if it's just a question of typing less,
bb will never compete with the ubiquity and flexibility of a shell's
yeah, I agree, but it would be cool to have a cross platform way of aliasing, regardless of your shell
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.
~/.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 😉
yeah, I'm aware; just if you allow
bb foo and it becomes popular, you will never be able to take it back. :]
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
So it won’t break users. Users will simply not have access to the new feature if their usage shadows it, which is not breaking since they didn’t use the new feature yet.
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
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.
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 😄
The httpkit server only supports http so if I need https then I have to use some proxy or something, right?