Fork me on GitHub

This is especially convenient for inline tasks:

  [:shell "clojure" "-M:outdated:nop:1.8" "--exclude=clojure/brew-install"]
  [:shell "clojure" "-M:dev:1.9:test"]
  [:shell "clojure" "-M:dev:test"]]


Yeah looks good! And I guess you can have :and or :or this way too. Very concise!


:do is :and as in, it will shortcut on the first failing job. not sure about :or since or in clojure shortcuts on the first truthy value which is not common with tasks


ah yeah I see. :&& and :|| also seem to be valid symbols. But might be to bash-y for babashka :)


I considered those, but they don't work inside the command line as they will be picked up by bash


Will this syntax also be usable from the command line?


That is what I initially supported with :do:

bb :do :foo 1 2 3 :and-do :bar 1 2 3


but this is not longer supported now with the rewrite to hiccup


so probably not


I’m guessing the following will also be valid? (the last :do part)

{:paths ["test-resources/bb-edn"]
 :deps {medley/medley {:mvn/version "1.3.0"}}
 :tasks {:shell1 ^{:description "Echo hello"}
         [:shell "echo" "hello"]
         :shell2 ^{:description "Echo bye"}
         [:shell "echo" "bye"]
         :medley ^{:description "Show off medley"}
         [:babashka -e (do (require (quote [medley.core :as m]))
                           (m/index-by :id [{:id 1} {:id 2}]))]

         :shell-all [:do :shell1 :shell2]}



[:do [:shell1] [:shell2]]
that already works


I just want to say how cool, easy and incredible was to implement integration-tests in clojure-lsp using babashka:

❤️ 9

(BTW It's really incredible how fast sci return an error if there is something not right in your code)


Thanks man, this is always nice to hear

❤️ 3

Yeah, I feel the babashka awesome too. Maybe I mention it too much? Nah!

❤️ 9

I want to do this at work but there would be too much opposition 😢


@U01KUQRDMLG sounds like you are at the wrong place 🙂 what's your opposition's reasoning, btw? maybe there wouldn't be that much opposition, you are just assuming it? also, try it for yourself first on some of the work problems you have and maybe you will realize that some of the reluctance is well-founded... for example in the company i work for, we still have tension because of the different editors and the lack of consistent code-formatting tools for clojure.


just bringing in a new language is always difficult. I use babashka for my own purposes

Tomas Brejla20:03:54

(not sure whether its better to ask here on in #calva, but I'll try this channel first, as the question is also very bb-specific) When I open bb --nrepl-server and then connect to nrepl port 1667 in calva, the editor is offering code completion for namespaces, imports of java classes, function names etc. But it's not able to offer function parameter names/positions, function docs etc. Is there any way of getting this functionality in calva when connected against bb's nrepl server?


I'm open to receive a PR for this


These nrepl ops are currently supported:

#{"clone" "close" "eval" "load-file"
                                              "complete" "describe" "ls-sessions"
I think eldoc comes relatively close and might offer you some insight in how to implement the other one


^ @U0ETXRFEW is the above issue still relevant?


Oh, yes. Would be magical!

Tomas Brejla01:03:28

It took me a while to figure out how to prepare a REPL-driven-development experience where I can make modifications to the code and see the result in a few seconds, but it's slowly starting to work. It's a bit buggy, but quite awesome. Developing scripts against bb --nrepl-server with calva will be way better with parameter support and docs. Found posible issues: 1. when you use (:require with :as aliasing of some namespace, function name completion of that namespace will get duplicated. Perhaps there's already some error present in current version in :complete message handling or something similar? 2. if I use such aliasing, (such as s/includes? where s is alias for clojure.string), this new info functionality works fine in function name completions only when you use full namespace, not when you use the prefix form. If prefix is used, a bit weird combination of namespace and symbol seems to be passed in the message. In mentioned case namespace=clojure.string and symbol=s/includes? . I don't know what's the contract of this message, but this combination doesn't feel right (I'd expect that the symbol shouldn't include the s/ prefix). But as I said, I don't know the contract. 3. some of the functions seems to be missing their docs, such as , possibly because protocols are implemented in a bit different way in babashka? It might also be possible to get some really basic information about java class methods (even without reflection), such as the types and positions of their parameters. But I'll have to look more into that. Here's a short video of current status. Will need to clean that up a bit tomorrow or some following day and file a PR.


Awesome. Don’t hesitate to ask me for help if there is anything on the VS Code end of that that you think I can shed some light on. The nrepl “contract” I don’t know as much about as one would think. It has mostly just worked for me and I’ve been reverse engineering CIDER when I wonder about how to do some particular thing.


The info op doesn't seem to be documented. @U051BLM8F should it be?


@U04V15CAJ There's no info op in nREPL - that's in cider-nrepl. The nREPL op is named lookup.


@U051BLM8F should calva then use the lookup op if info is not available? and what should be in this map? > Returns :info A map of the symbol’s info. The doc is pretty handwavey here.


Is lookup the same as info?


Everyone should use lookup if info is not available. As for the :info map - I agree it needs more documentation.


@U051BLM8F So maybe it's best if @brdloush exposed his new op as both info and lookup? Are they drop-in replacements?


The API is the same and I think it's fine to expose both as aliases. Eventually I'll rename cider-nrepl's op cider/info to it's clearer that it's not built-in, but I don't have any concrete roadmap for this. Not sure how many client have been updates to support lookup by now, as it's still pretty new.


ok cool. copy that @brdloush? :)

Tomas Brejla17:03:52

@U04V15CAJ copy @U0ETXRFEW I have some issue with calva not showing the docs on code completion. At some point, I managed to see the completion options in that way, that both the argument list and documentation reside in their own popup window (first screenshot). But now I'm always getting just a single-window code completion popup, where the parameters are included in that single window. (second screenshot)

Tomas Brejla17:03:11

And I just don't see why the code completion is now getting rendered in that single-window form instead of two-window form. Any hint appreciated 🙂

Tomas Brejla17:03:02

aaaaah, I am soooo stupid 😄. All I had to do was to CLICK that area with params 😄


Is that a babashka repl?

Tomas Brejla17:03:18

aaah, the shortcut to switch between the single-window and multi-window code completion is ctrl+space. Now I understand how it happened that I accidently switched between the two modes 🙂

Tomas Brejla18:03:11

After a few fixes, It's starting to behave as I'd like. I'll do some more testing in the evening and hopefully file a PR.


So beautiful. You are a hero!


@brdloush Calva relies on cider-nrepl and clojure-lsp for these things. So far there is no cider-nrepl in babashka's nrepl server, and clojure-lsp needs dependency info. You might get away with creating a deps.edn file with the dependencies you use. At least for some of the functionality.


I tried running the following script on Windows under Git Bash, but using Windows-native bb.exe as installed by Scoop:

#!/usr/bin/env bb
(println "Hello, world")


This script failed for me with the following error:

Message:  File does not exist: /cygdrive/c/Users/blah/bin/hello


The problem is that the native bb doesn’t recognize Cygwin paths. My solution was to create a script called bbw on my Cygwin path:

bb.exe $(cygpath -w $SCRIPT) $@


Maybe your script can just be called bb so you can run scripts cross platform without changing the shebang


…then change the shebang in my original script to use bbw:

#!/usr/bin/env bbw


Would this be a common enough problem to note in the Babashka book?


So why does bb.exe not recognize that path?


cygpath -w translates it to a Windows path?


I think adding it to the book might be good. Maybe we can have a troubleshooting chapter


Or under "recipes" we can add a cygwin section


My bb.exe is not from cygwin, so it doesn’t recognize /cygdrive style paths.


yeah, makes sense and so your wrapper script is only available in the cygwin shell right?


ok, so maybe calling the script just bb is nice so the shebang is the same in bash as it is in cygwin


Hrm, the problem is the wrapper assumes the first arg is the name of a script. Naming the wrapper bb would prevent me from doing bb one-liners from bash.


oh you mean WSL2?


oh you mean, bb -e '(+ 1 2 3)' for example, I get it now.


We can’t install WLS2 on our work machines so Git Bash is the only way to hold onto a little bit of sanity 🙂


you can either make a PR for the book, or post the snippets here:


@U0DTSCAUU this sounds like a niche problem caused by social/organizational issues ("We can’t install WLS2 on our work machines"). instead of silently trying to overcome a social issue with software workarounds (further complicating the existing software, what's already hyper complicated, i guess), i would try to attack this problem from a social angle and solve it that way. and if you can't change the organization around you, then u should probably start looking for other ventures, which value your lifetime more and let you solve more impactful problems. these kind of rigid companies deserve to wither away; better u don't help keeping them alive... :)


I dunno, I think restricting admin access is just prudent security policy, not necessarily the sign of a rigid company that deserves to wither away.


This is the case in many companies, it's always nice to have escapes


i've excused myself from the ms windows world decades ago, so i don't have up-to-date insights on this topic. what's wrong with allowing the installation of WSL2? @U0DTSCAUU do you agree that it's a "prudent security policy" to disallow installing WSL2 (which is an official part of the OS, just not installed by default, if i understood correctly)? are you sure that they specifically disallow WSL2 or you were just denied by reflex? is there any documentation available about this decision to the employees? if not, then sorry, it's a shit company; let


let's not try to sugar coat it...


@U086D6TBN Please don't be rude and respect other people's choices, or not, but I don't see a need to nag them about it.

👍 3

all im saying is, don't just give in so easily. many limitations are self-imposed. often u just have to ask and you will receive. and DO be a bit of a pain in the ass sometimes, because that little extra push is all that's necessary for other people to realize their own self-imposed limitations. meaning, however is the gatekeeper for the WSL2 installation, might give in and think about it for a few minutes, if asked every week 4 times in a row. demand a clear explanation the very least. @U04V15CAJ is it less rude if i put it this way? i've noticed that my threshold for directness and abrasiveness differs from other nations' thresholds. i never had such issues with ppl from eastern-europe...


Fair points, but you don't always know the situation people are in and they might have good reasons to be very conservative with what people can install on certain systems with e.g. sensitive information. My wife works for a company that deals with patient information and some environments she works in are very strictly controlled. I think you made your point well, thanks for clarifying.

❤️ 3