Daniel Kraus <dan...@kraus.my> writes:
> Ihor Radchenko <yanta...@posteo.net> writes: > >> Daniel Kraus <dan...@kraus.my> writes: >> >>> +(defcustom org-babel-clojure-backend (cond >>> + ((executable-find "bb") 'babashka) >>> + ((executable-find "nbb") 'nbb) >>> + ((featurep 'cider) 'cider) >>> + ((featurep 'inf-clojure) >>> 'inf-clojure) >>> + ((featurep 'slime) 'slime) >>> + (t nil)) >> >> What if users have, say, cider installed and also babashka executable? >> Will it be expected to use babashka? > > Yes. The only thing that makes me slightly hesitant is that e.g. > someone doesn't have `bb` installed. Executes clojure source blocks > which are then evaluated in, let's say cider. > Then they install `bb` and the next time they start Emacs, the same > source block on re-evaluation would be executed with babashka. > > I think this is still the best out of the box experience as it > "just works" for most users without having to customise something > and if they want it fixed, they can pin it to a certain backend. > > What's your opinion? > > Cheers, > Daniel Just chime in with my 2 cents. I think bb is a much better solution from a babel perspective and would love to see it as the default, even when you have both bb and cider installed. I stopped using clojure in org because it was way too fragile - depending heavily on cider features which often changed. However, now we have babashka and nbb, I'm thinking about using org again with clojure. I recall looking at the babel code for clojure some time back to see if it could be made simpler and more reliable. However, there wasn't much that could be improved on given the design of cider and its focus on interactive clojure development. I then thought using something like the Clojure CLI tools might be the way to go. Now I feel that babashka for clojure and nbb for clojurescript might be the right answer.
