Suppose I'm writing a simple k/v store as a cli tool:

bb -x devtools.mymodule/get --key a

The code looks like this

(defn do-get [k]
   ...)

(defn get
  {:org.babashka/cli {:require [:key]}}
  [{k :key}]
  (println (do-get pit-dir k)))

Two questions: • devtools.mymodule/get clashes with clojure.core/get. But I'd rather not limit my external cli interface to names not occurring in clojure.core (so many good names are taken) • I typically write a pair of functions: do-foo - which is unit-tested - and also a CLI wrapper function foo which isn't unit-tested and just injects dependencies and supplies CLI args. But what is a good naming convention for this pair?

Maybe frivolous but it keeps bothering me

> But I'd rather not limit my external cli interface to names not occurring in clojure.core (so many good names are taken) Well, you can use (:refer-clojure :exclude [get]) but this gets old fast, since get is so commonly used, so perhaps (and also to address point two) you can just expose one cli namespace where you have these CLI wrappers and then you invoke your other functions from there?

yeah I could also create one .cli namespace per ns that needs it...

you can also do this via tasks in bb.edn: just give the task the name you want and then invoke the function using exec

e.g.:

{:tasks {get {:task (exec 'devtools.mymodule/get)}}}

That's a great option as well. The reason I really liked -x was that it doesn't require registering the task in a a centralized place (bb.edn). Instead the configuration is colocated with the code itself. But maybe I'll just need to drop one of these desiderata

You mean a TUI right?

You can use bblgum to do some basic stuff like displaying text, dialogues, etc: https://github.com/lispyclouds/bblgum This depends on gum to be installed. There's similar other stuff as well. It all works by shelling out indeed. An alternative is to build a TUI via #nbb and use something like ink. You can find that in the project README of nbb.

Oh great, thanks a lot!

Yes TUI