Add config option to customize 'No such task' behavior

[cldwalker]

Hi @borkdude 👋

Is your feature request related to a problem? Please describe.
I'd like to be able to customize the behavior when a task is not found

Describe the solution you'd like
Support a top-level config option that takes the task not found and maybe any args e.g.

:task-not-found (fn [task args] (run 'default-task))

Some use cases I could use this for:

• Give a different error. Useful for commands like lq that are basically wrappers around bb
• Allow users to auto-alias tasks on the fly if they'd like - for example
• Fallback to a default command

Describe alternatives you've considered
I don't know of a way I can patch the internals since it seems hardcoded

Additional context

Happy to work on this if you agree it'd be helpful

[borkdude]

Yeah, we could have :default "hook"

:default (fn [{:keys [...]}] ...)

and we can add stuff to the input map. The default task then becomes responsible also for bb not-found.clj usage I would say?

[borkdude]

Btw, would it make sense to make a datascript pod, so that component becomes more re-usable for other bb users/scripts as well? There's already a datalevin pod btw:

https://github.com/babashka/pod-registry/blob/master/examples/datalevin.clj

[borkdude]

Maybe we should stick to the non-function approach:

:default (run 'default-task)

and we can add stuff to (current-task) which can be used in that default task. Args can already be accessed via *command-line-args*.

[cldwalker]

Maybe we should stick to the non-function approach:

:default (run 'default-task)

and we can add stuff to (current-task) which can be used in that default task. Args can already be accessed via *command-line-args*.

Sounds great 👍 Hopefully I'll get to it this weekend

[cldwalker]

Btw, would it make sense to make a datascript pod, so that component becomes more re-usable for other bb users/scripts as well? There's already a datalevin pod btw:

https://github.com/babashka/pod-registry/blob/master/examples/datalevin.clj

That would definitely be nice. I didn't see much documentation on building releases and I don't have much personal time to do this. If I give this a try, what would be the easiest example to copy from?

[borkdude]

If I give this a try, what would be the easiest example to copy from?

@cldwalker Probably buddy (recently updated) or datalevin (since that's close to datascript).

[ieugen]

I'm also looking for something like this.
My use case is to have an easy way to call bb tasks from a central location.
I would like to have a bb.edn where I can register tasks from other bb.edn in other directories.

One way I can do that is to read bb.edn files and register tasks dynamically, based on the tasks I find in those files.

Simple way of doing this:

{:tasks {:requires ([clojure.string :as str])
         app {:doc "Without arguments, prints tasks in app - with arguments, invokes task in app dir"
              :task (if (empty? *command-line-args*)
                      (shell {:dir "app"} "bb tasks")
                      (shell {:dir "app"} (str "bb run " (str/join " " *command-line-args*))))}}}

Using a default function I could implement the logic based on the command line parameters.
I could scan a list of directories (or all subdirectories) for bb.edn and register them as available tasks.

[borkdude]

Another alternative is to generate the bb.edn once based on the available directories, using a script.

[ieugen]

I'll think about it and maybe try it out.
if the tasks are static yes, but then people would have to remember to re-generate the script when changes happen (maintenance).

[borkdude]

@ieugen That is true, but I expect the churn of subdirectories in a project to not be so high that this becomes annoying. Also there are ways to automate that by e.g. adding the bb.edn re-generation as a task dependency of other common ran tasks or as a git pre-commit hook, or both. I've done that e.g. here in clerk:

Installing the git commit hook, happens when invoking a task
https://github.com/nextjournal/clerk/blob/9a04cf38fd4d7c771071ddc14538da673cd32f4f/bb.edn#L75

And the actually pre-commit hook executes a task which refreshes a file (in this case a SHA, but in your case it would be the re-generated bb.edn):

https://github.com/nextjournal/clerk/blob/main/dev/pre-commit

[borkdude]

Another thought, what about:

bb app/task

which executes a task in directory app

So this would be equivalent to:

cd app; bb task

Not entirely sure if that's a good idea or not, but currently it was already not possible to use slashes in task names, so it should at least not be breaking.

[borkdude]

And possibly bb tasks could also print the tasks in subdirs, but as separate groups.

bb tasks

foo Task in current dir

app/task2 Task in dir app
app/task1 Another task in dir app

[ieugen]

I think both approaches have merit.

[borkdude]

Let's continue the discussion about tasks in monorepos here: #1044
It seems to be a slightly differerent use case as the :default fallback.