Rewrote task DSL to a more hiccup-style syntax: https://github.com/babashka/babashka/discussions/757#discussioncomment-529074
nice!
This is especially convenient for inline tasks:
[:do
[: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 worksNice 🙂
I just want to say how cool, easy and incredible was to implement integration-tests in clojure-lsp using babashka:
I want to do this at work but there would be too much opposition 😢
@grazfather 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
(BTW It's really incredible how fast sci return an error if there is something not right in your code)
(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?
nice!!
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. https://nrepl.org/nrepl/ops.html @bozhidar should it be?
I was mostly trying to look up the structure and value types from cider-nrepl
's tests
https://github.com/clojure-emacs/cider-nrepl/blob/a7d24bc91028b78eda2f73a6d3f17c53495a84da/test/clj/cider/nrepl/middleware/info_test.clj#L85-L255
@borkdude There's no info
op in nREPL - that's in cider-nrepl
. The nREPL op is named lookup
.
@bozhidar 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.
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? :)
@borkdude copy @pez 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)
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 🙂
aaaaah, I am soooo stupid 😄. All I had to do was to CLICK that area with params 😄
Is that a babashka repl?
yes
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 🙂
After a few fixes, It's starting to behave as I'd like. https://www.youtube.com/watch?v=BxR5oE9pKAI I'll do some more testing in the evening and hopefully file a PR.
So beautiful. You are a hero!
awesome :)
I think this issue is related to this: https://github.com/babashka/babashka.nrepl/issues/30
I'm open to receive a PR for this
These nrepl ops are currently supported:
#{"clone" "close" "eval" "load-file"
"complete" "describe" "ls-sessions"
"eldoc"}
I think eldoc comes relatively close and might offer you some insight in how to implement the other oneThanks man, this is always nice to hear
@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.
^ @pez is the above issue still relevant?
Oh, yes. Would be magical!
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:
#!/bin/bash
SCRIPT=$1
shift
bb.exe $(cygpath -w $SCRIPT) $@
…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?
@jkrasnay 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? @jkrasnay 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...
@onetom 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.
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. @borkdude 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.
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
Maybe your script can just be called bb
so you can run scripts cross platform without changing the shebang
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?
Yep
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.
Yep
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: https://github.com/babashka/book/discussions/categories/ideas
Yeah, I feel the babashka awesome too. Maybe I mention it too much? Nah!