Babashka standalone example

[borkdude]

Hi @kkinnear! I was trying to come up with a standalone zprint example in bb. E.g. to print a colorized output of the script itself:

(ns zprint
  (:require [babashka.deps :as deps]))

(deps/add-deps '{:deps {org.babashka/spec.alpha {:git/url "https://github.com/babashka/spec.alpha"
                                                 :git/sha "1a841c4cc1d4f6dab7505a98ed2d532dd9d56b78"}
                        zprint/zprint {:mvn/version "1.2.3"}}})

(require '[zprint.core :as zp])

(println (zp/zprint-file-str (slurp *file*) {:color? true}))

How do I make this work with colorized output?

[borkdude]

Figured it out:

(ns zprint
  (:require [babashka.deps :as deps]))

(deps/add-deps '{:deps {org.babashka/spec.alpha {:git/url "https://github.com/babashka/spec.alpha"
                                                 :git/sha "1a841c4cc1d4f6dab7505a98ed2d532dd9d56b78"}
                        zprint/zprint {:mvn/version "1.2.3"}}})

(require '[zprint.core :as zp])

(println (zp/zprint-file-str (slurp *file*) "yolo" {:color? true :style :dark-color-map}))

[kkinnear]

That's very neat! I had to change the color map since I couldn't see it, but I was impressed at how fast it ran.

While I use babashka in my testing, it is only in a very limited way. As yet, anyway. I haven't played around with it using zprint much. But your example prompted me to try to make a zprint babashka script. I looked at your examples in the babashka repo and what you shared above, and came up with this. Which, rather astonishingly, worked the first time I tried it!

projects/zprint % more zprint.clj
#!/usr/bin/env bb
;;
;; Same UI as the zprint graalVM images.
;;
;; ./zprint.clj --help
;;

(ns zprint
  (:require [babashka.deps :as deps]))

(deps/add-deps '{:deps {org.babashka/spec.alpha {:git/url "https://github.com/babashka/spec.alpha"
                                                 :git/sha "1a841c4cc1d4f6dab7505a98ed2d532dd9d56b78"}
                        zprint/zprint {:mvn/version "1.2.3"}}})

(require '[zprint.main :as zm])

(apply zm/-main *command-line-args*)

It seemed to run pretty quickly, so I did a couple of tests comparing it to the graalVM version and the uberjar.

In the table below, the graalVM version is zprintm-1.2.3, and the uberjar is java -jar zprint-filter-1.2.3.

Processor	672 loc	2262 loc	7753 loc
zprintm-1.2.3	0.7	1.2	4.1
zprint.clj	1.6	3.0	11.9
java -jar zprint-filter-1.2.3	2.0	2.9	4.4

For most reasonable sized files, babashka is a perfectly usable way to use zprint. The big file, at 7753 loc, is really larger than it probably should be.

I'm thinking of including a section in the zprint doc about how to use zprint with babashka. The nice thing about the script above is that you don't have to download anything to get the next version, you just have to edit the script. There might even be a way to have it get the latest version, perhaps.

I'm a bit unclear as to the relative utility of babashka "tasks" and babashka "scripts". The testing thing you made (which I completed, by the way -- it now does all possible tests) is a "task". But your examples are "scripts". I'm not sure why one might choose to use one or the other.

Anyway, if there is anything you think I should improve or change before I added this to the doc, I'd love to hear about it. No particular rush, I've just started work on the next release so it will be a while before I release again.

[borkdude]

@kkinnear Both tasks and scripts have their usage. I see tasks as a way to replace Makefiles and get a grip on what are the common actions in a Clojure project. I usually have a bb dev task which starts a REPL (or more stuff at the same time like CLJS compilation, etc). And a bb publish task that deploys something to Clojars or an extension to VSCode Marketplace, or a package to npm.
Scripts on the other hand, I usually place in my global bin folder so I can execute them from anywhere. I also think that these standalone scripts are a nice way to share small examples where everything fits in one file. Feel free to add it to your README.

Thanks for this table!

[kkinnear]

Well, some additional testing indicates that I have some more work to do if I want to advertise a babashka zprint script as largely equivalent to the uberjar or graalVM binaries. The biggest problem seems to be that, to get zprint to work with babushka, I appear to have left out zprint's use of sci, so any functions defined in external option maps don't work. To be specific, here is what I did to make zprint work in babashka:

 (def opts
  {:namespaces {'clojure.core {'jrequireguide zprint.guide/jrequireguide,
                               'defprotocolguide zprint.guide/defprotocolguide,
                               'signatureguide1 zprint.guide/signatureguide1,
                               'guideguide zprint.guide/guideguide,
                               'rodguide zprint.guide/rodguide,
                               'areguide zprint.guide/areguide,
                               'odrguide zprint.guide/odrguide}}})
(def sci-ctx
  #?(:bb nil
     ;:clj nil
     ; To completely remove sci, include the previous line and comment
     ; out the following line.
     :clj (sci/init opts)
     :cljs (sci/init opts)))

(defn sci-load-string
  "Read an options map from a string using sci/eval-string to read
  in the structure, and to create sandboxed function for any functions
  defined in the options-map (i.e. in the string).  Any failures
  from eval-string are not caught and propagate back up the call
  stack."
  [s]
  #?(:bb (read-string s)
     ; :clj (read-string s)
     ; To completely remove sci, include the previous line and comment out
     ; the following line.
     :clj (sci/eval-string* sci-ctx s)
     :cljs (sci/eval-string* sci-ctx s)))

There is probably a way around this, but I'll have do a bit of work to figure that out.

Anyway, it is certainly something to work on!

[borkdude]

The solution to this would be to expose SCI itself in babashka, which is certainly a possibility.

[kkinnear]

Yes, that would be very helpful!

Prior to seeing your response, I was just pursuing the babashka docs, and I saw that you expose babashka/fs, and was wondering if it would be possible to expose babashka/sci, since it is obviously already there. I don't know if there would be some downsides to that, since probably nobody else really needs it or it would have come up before, but if it wouldn't hurt anything, that would be really great for zprint.