Fork me on GitHub

I'm contemplating to create a babashka.json library which abstracts over, cheshire, jsonista and possibly more. The idea is that people can use this in bb scripts and as a JVM dependency, without worrying which concrete JSON library is being used and without having to write reader conditionals to dispatch between bb or CLJ, if people want to use a different library than cheshire on the JVM. The implementation will be provided by either one of those libraries on the classpath. Does this feel useful to anyone, but me?

👍 16

the one use case that affected me at times was using bb to parse and walk over through massive (70MB+, hundreds of millions of nodes) jsons. seemed to offer the best perf and used it via the JVM. Would've been nice to use bb as the surrounding code wasnt big or long running enough for a JVM.


also that's me requesting to consider charred too 😄

👍 2

sure, can add more impls


I would like this. I generally like to default to data.json except use Cheshire when targeting babashka since it's built in. Not a huge deal but the fn name differences get me every time. I've been loving the babashka suite of libraries as good sensible defaults that work across clj and bb and would definitely use a json one. For me the pluggable implementation is a bonus (but good idea!)

👍 2

Yes, I think defaulting to is a good one unless it's not present or otherwise specified with a system property or so


controversial choice: the keywordize function defaults to keyword

👍 8

I like that choice! Going to start using it now, seems to already cover 95% of my json usage haha.

Rupert (All Street)16:03:03

I think - is meant to be much faster than cheshire - so unless cheshire has a particular adgante, perhaps jsonista would make it a better default?

Rupert (All Street)16:03:34

Cheshire seems to mostly be popular from its first move advantage - but other libraries seem to have surpassed it and in many cases probably shouldn't be used.


The main rationale for cheshire is to support the babashka use case. It is bundled there and would not need bundling another lib too. cheshire isnt really the default here as well as the lib tries all of them in an order. technically data.json is the default as its part of this lib's deps as well


this lib doesnt enforce the use of any particular lib, but strives to provide a coherent interface. as for defaults, data.json is the simplest of them all hence fits as a convenient default which runs both on bb and jvm. all others either bring in significant dependencies along and/or need special things like java compilation along with difference of api/usage/idioms

Rupert (All Street)17:03:26

data.json being pure clojure and not tied to the JVM is fantastic. No problem with that library. It's just the continued use of cheshire for new projects that I think should be discouraged or challenged a bit more often. The automatic library selection idea sounds good. So I guess cheshire should be last lib to try on the list (since it's built into BB it will always suceed there). Might be good to allow the user to customise/influence the load order if they wish to.


yeah its there already by setting the system prop babashka.json.provider.

👍 2

i myself almost always use charred. its faster than jsonista too 🙂

Rupert (All Street)17:03:47

Sounds good - I'll definitely look into that one.


and pulls in much much less deps compared to it as well


zero deps in fact

Rupert (All Street)17:03:27

Cools - that's often a good selling point.


data.json is tied to the JVM

Rupert (All Street)18:03:45

:dependencies [[org.clojure/clojure "1.10.3"]]


> It's just the continued use of cheshire for new projects that I think should be discouraged or challenged a bit more often. That's in line with the goal of this library: people can use whatever lib they want, as long as they use babashka.json functions


Rupert: what exactly do you mean

Rupert (All Street)18:03:52

I mean that's the list of depdencies for data.json - so it doesn't' look tied to the JVM. I guess it is .clj and not .cljc so not really for clojurescript.


> it doesn't look tied to the JVM Well, it only runs on the JVM


porting it to ClojureScript has very little use since JS has JSON support built-in

👍 2
Rupert (All Street)18:03:13

I guess what I mean is that it's pure clojure + zero dependency so in theory it should be more portable than other JSON libraries like cheshire.

Rupert (All Street)18:03:49

> That's in line with the goal of this library: people can use whatever lib they want, as long as they use babashka.json functions Sounds like a good library to me then 🙂 .


Hi, is there an option in babashka.tasks/shell to echo the executed command in the context of bb.edn? I came up with

(shell {:pre-start-fn (comp (partial println) (partial clojure.string/join " ") :cmd)} "echo" "hello" "bb")
;; => c:\usr\bin\echo.exe hello bb
but this looks more like a hack. thanks


That's exactly what :pre-start-fn is for


Indeed, but I think a shell echo option is worth to be a first class option rather than try to hack something around :pre-start-fn.


:echo true


Either this or perhaps a babashka.process/*echo* dynamic var that can apply to all invocations?


There's already babashka.process/*defaults* for this


but I don't think you can use it from bb itself yet, we can fix that


right, I didn't know about *defaults* , perhaps worth mentioning in the process' file. Shall a raise a new issue/feat req in babashka for :echo or you want this to be reflected in babashka.process instead?



(babashka.process/echo true)
(babashka.process/echo false)
could also be nice. Yes, I think an issue in babashka/process is best


Maybe a function (babashka.process/set-default :echo true) or so is better


and more portable between JVM and SCI


as a convenient addition to rebinding/setting babashka.process/**defaults** ?


needs a little bit of thinking

Matthew Twomey15:03:47

I think babashka doesn’t currently support clojure.core.reducers, is that correct? (I think just seeing that the namespace doesn’t show up indicates that is the case, I’m just not 100% confident that this is the correct way to check).


This is correct. In many cases reducers has been caught up with transducers (according to the core team) so it seemed a bit of a waste of binary size to add it, since almost nobody in bb is using it

Matthew Twomey15:03:03

ok - thanks, just checking. I don’t “need it”. I was just learning some stuff.

👍 2
Matthew Twomey15:03:16

(babashka is a nice env to try stuff out in)

yes 2