Clojurians Log v2

New Youtube video! bb 0.3.1 new features: - bb.edn - run any function as a main function https://youtu.be/_zr1dicJs-E

Awesome, definitely want to use it for my build tasks. For small projects these cmdline invocations usually end up in my README. For larger projects I normally automate it in a build file (like MAKE indeed) ... In both cases I'd prefer to have the tasks as executable clojure code on my machine 🙂

You’re a machine

What do you think about suppressing full stack traces for errors, with maybe -v to get around?

bb doc ~/x spews a huge stack trace, for example

@grazfather usually users should not see an entire stacktrace unless they use --verbose, so feel free to post an issue for doc, it should handle it better

sure

https://github.com/babashka/babashka/issues/770

tnx

np

Hey, really nice video! Does this version supports getting the classpath/deps via a bb command?

no, not yet

Exited for that 😄 bb is becoming a pretty mature clojure tool

super!

@borkdude is there any way to set default ns? Instead of bb -m tasks/foo I would like to write bb -m foo

Not yet, but I think this was also something that @lee suggested. Feel free to post an issue and we could maybe add an option to bb.edn

@borkdude bb -h has a typo for nrepl-server locahost:1667 should be localhost:1667

@mike1452 thanks, will fix

babashka is very cool. experimenting with it to completely remove just utility from my templates.

@mike1452 https://github.com/babashka/babashka/discussions/765#discussioncomment-544282.

Yeah, instead of an issue we might continue rambling there

Hey, turns out you can do a heck of a lot with 50 lines of Babashka. Here is Borkdudes birthday calculation fleshed out

https://github.com/heow/lifecalc

If you are for, or fiercely against including rewrite-clj in babashka, make your opinion known here: https://github.com/babashka/babashka/issues/769

pretty cool stuff!! the only thing I miss from it is a way to list the available tasks (and maybe have a way to tab-complete them from the terminal?). I was thinking we could add some metadata to the fn name to flag it as a "task", a problem there is to figure which files to scan, maybe use a file name pattern (eg: *-tasks)

@wilkerlucio good thoughts, this idea has come up before and I'm happy you bring it up again. there are a few ways to solve this: 1) add the tasks manually to the docstring of the ns using alter-meta! and then request the ns doc with bb doc tasks 2) implement a generic dir subcommand that lists all public vars of a namespace: bb dir tasks 3) implement a bespoke subcommand for this: bb list tasks which searches in the tasks ns for vars that have specific metadata 4) like 3 + set the namespaces to list in bb.edn

I like the idea of flagging the tasks ns manually in bb.edn, this way we have good control, and just have to setup once per ns

so 4?

damn are you saying borkdude is half dead?

👍

I created a sub-discussion for this idea here: https://github.com/babashka/babashka/discussions/771

if we go with custom tasks designated with metadata we could also have bb run install and then bb knows in which namespaces to find install

I think that ties into the thing that @mike1452 brought up: having a shorter way of invoking tasks by name

yeah, I posted on the discussion, I think if a task name is unique (no conflicts), babashka could accept just the name without the ns

One other possibility could be to name the task in bb.edn:

{:tasks {install foo.bar.tasks/install}}

@wilkerlucio The way I got to the DSL discussed in the video was as follows: start with {:tasks {install foo.bar.tasks/install}} but perhaps you want to add some options:

{:tasks {install {:main-fn foo.bar.tasks/install :description ...}}}

{:tasks {install {:shell "ls"}}}

{:tasks {uberjar [main foo.bar/baz]
         install [shell "ls"]}}

This is why I started with the most basic thing

They also call @heow Heow The Reaper

kind feels like a snake eating itself (going back to the DSL idea)

but also makes me think about package.json scripts, they are a nice a way to alias simple things

right

the question is how far should a dsl like this go

in npm they chose: just shell invocation

in gradle they chose: allow every magical thing (I think)

in bb we choose: just functions?

what about 2 options: - use a symbol to point to fn - use a string to shell

the best of both worlds, convenience and extensibility via fns?

that's what I'm thinking

{:tasks {clean "rm -rf target"
    install foo.bar.baz/install}

yeah might make sense. we can always extend this with a config map as the third type if we must

and you can invoke bb itself for clojure invocations as well: ` {:tasks {repl "bb clojure -A:foo" install foo.bar.baz/install}

or invoke the normal clojure of course

yup

now that tempting feeling for hiccup to give args to the fn XD

we can do via shell alias, but also giving data as EDN strait also sounds nice

maybe, instead of hiccup, make it look like a fn call

{:tasks {install (foo.bar/install "with" :args)}}

not sure how much that sounds a stretch, but if we just allow generic clojuer to run there, is a full Clojure for free :thinking_face: altough detecting fns to auto-import may get too much

@wilkerlucio getting close to https://github.com/juxt/mach ;) in the dsl I had that like [main foo.bar/install "with" :args] where main was one of main, clojure, shell

😂

I like lists instead of hiccup in this case because it feels more natural (same as invoking in clojure), do you have a strong opinion on using hiccup style instead?

Mach looks interesting

note that it is abandoned according to JUXT itself (reason was that nodejs wasn't a good fit for this kind of synchronous work)

in my head is making a lot of sense to enable code snippets strait in the config, seems to solve the "custom DSL" problem (just relying on all clojure constructs instead), while giving a lot of power. this way the decision to make a or not it as a external fn defined in a file can become a refactor decision (when things get messy)

true, but all requires are done implicitly?

we could also expose a function (babashka.tasks/shell "rm -rf target")

or (shell "rm -rf target") for convenience (but comes from that utils ns)

yeah, I wonder if there would be issues with all requires done implicitly, but I guess if the snippets are small it should be fine

yeah, I'm down to some extra includes for convience (on scripts running from "task snippets")

like the helpers you got in the video demo

it would be pretty bb-esque to allow scripting there ;)

and calling another task by name, implicitly inlines the script?

{:tasks {clean (shell "rm -rf target")}
  uberjar (do (clean) (tasks/uberjar))

maybe clean (shell "rm -rf target") defines a function in the background which you can call?

(letfn [clean ([] (shell "rm -rf target")) ...

what about bb.task/clean? trying to think a way to reduce collisions

why would you have collissions by having them as local fns?

I wonder for example, if I have a task called empty, that would shadow clojure.core/empty? maybe I'm being over-concerned here

I like the idea of being able to call other tasks, just wonder if there is a safer option

yeah, that would just be a bad task name then :)

also, the user could still use clojure.core/empty skip the shadowing

yeah

and given the task names are visible in place there, seems easy enough to track

man, that readme ended darkly...

@heow This is fantastic, I really like the trick of rotating though representations (date -> day -> percent -> date...)

and interleave-with.clj? that looks like a neat standalone script