What is driving the inclusion of spec in either version?

Excellent question. Some people like to validate their command line args with spec: https://github.com/l3nz/cli-matic/issues/113 Some people like to generate data from specs. Instrumenting functions during script development (may be far fetched). There's probably more command line applicability to spec, but maybe it's not really an urgent thing to have. @U0FT7SRLP also had a need for it. Earlier requests resulted in a library which can be interpreted and is not built-in: https://github.com/borkdude/spartan.spec

If you have any thoughts on this, I'd like to hear them. Btw, the version with the uberscript fixes was released (0.2.0).

Thanks for the release

I wonder how Clojure will incorporate spec alpha2. I suppose it could just include both versions so it doesn’t make a breaking change.

Good question. I'll ask in #clojure-spec

Regarding my use case, I was working on a cli tool for launching cloudformation stacks. I wanted to validate these templates with Spec (and expound). At the time it was unclear (to me) how Spec could work with Graalvm. Now there are more examples of this option, but being able to use spec for things like this, without needing to set up a graalvm project makes things easier and cheaper

Can spec not be used with bb by adding it to the class path?

Right now it can't. That's why I have created spartan.spec

At least at the time there were several limitations. And having spec built-in will make it run lots faster

Malli might also be interesting to look at, since it's more data driven

Mali does indeed look very interesting

Ah yeah regarding speed, I had a cli parser with spartan.spec and it was indeed to slow https://gist.github.com/jeroenvandijk/c6cb6cdecfd5aa8e990c3765f3411c0f

I think it would be good to try it again, since there were several improvements concerning performance

True, I’ll do that tomorrow probably

$ time bb tasks.cljc options -a :foo
::foo
bb tasks.cljc options -a :foo   0.10s  user 0.03s system 93% cpu 0.135 total

Would making it easier to build graalvm native images reduce the pressure to include more things in bb?

There's one project that allows you to convert a babashka script into a Graal binary: https://github.com/MnRA/nativity

I think having a compilation step in between is always going to be a barrier, no matter how "easy", it will still take time and memory

There is also distribution. Is Brew a sufficient distribution mechanism for Linux and windows?

For things that are not used by everyone there is https://github.com/babashka/babashka.pods. It lends itself well for libraries that receive data and return data. Spec is probably not so suited for that architecture.

Brew doesn't work on Windows, but Windows has scoop, which is similar

Babashka pods do have the same distribution problems as other graal binaries

I think brew and scoop are nice solutions for distributing binaries

> I think it would be good to try it again, since there were several improvements concerning performance @U04V15CAJ The script is broken it seems (not sure if was working before). I’ve updated it so that the command generation will work. The spartan.spec version still adds quite some overhead 130ms vs 100ms.

time bb -f tasks.cljc
No task found for ''

Existing tasks
* options : Demonstrate the task options DSL.
bb -f tasks.cljc  0.09s user 0.04s system 89% cpu 0.140 total

time QUICK=1 bb -f tasks.cljc
No task found for ''

Existing tasks
* options : Demonstrate the task options DSL.
QUICK=1 bb -f tasks.cljc  0.06s user 0.03s system 92% cpu 0.093 total