Fork me on GitHub
#babashka
<
2024-06-27
>
growthesque05:06:44

noob-question: in the bb docs I only see a way to manually start a bb project, but nothing like lein's lein new app my-app. Is bb designed to not have such a feature on purpose, or just something that's in the roadmap?

stas06:06:17

bb and lein are different things conceptually and have different use cases, imo

growthesque06:06:04

well, the docs do say that babashka supports local edn files to setup and manage a project.

stas06:06:59

Yeah, you write or invoke tasks yourself in bb.edn. Pretty much the same as you would put your shell scripts in scripts/ free form. Nothing is prepackaged except the interpreter and the libraries

borkdude07:06:22

Perhaps you’re looking for #C03KCV7TM6F which has a new task

growthesque07:06:07

well my impression is that the clojure community is moving away from lein and towards clj with things like clj-new which is fine, but I was wondering why not use babashka for everything since it's so much faster than clj and lein?

borkdude08:06:45

well, bb isn't the same as JVM Clojure, it only supports a subset

growthesque08:06:02

is it possible to actually host full Clojure on GraalVM?

borkdude08:06:21

I have a couple of youtube talks on bb and the limitations of native-image (which you probably mean with GraalVM)

🙏 1
seancorfield17:06:36

@U05V9JANJQK Re: clj-new -- that should be considered "legacy" at this point and deps-new should generally be used instead. clj-new supports legacy templates (lein, boot) but those templates generally produce projects based on Leiningen or Boot. So that doesn't help you with the Clojure CLI :) deps-new is more declarative and is focused on Clojure CLI projects. I think all deps-new templates produce CLI-based projects (but, hey, a template can produce whatever the author wants!). As for Babashka, that's more for "shell scripting" style programming rather than wholesale server-side applications. For long-running server-side processes, JVM Clojure makes more sense than Babashka because you'll have full access to the entire JVM ecosystem and arbitrary Clojure libraries instead of just a subset.

growthesque17:06:03

@U04V70XH6 interesting, I just noticed that Kit was using clj-new in the documentation and thought this was relatively new

seancorfield17:06:37

I suspect that's because they already had a Leiningen-based template? (and didn't want to develop a deps-new template from scratch)

👍 1
M3tti07:06:52

did anybody had this issue before with babashka http-client

Inspector error for: {:status 500, :body "invalid upgrade response: status code 200\n", :version :http1.1, :headers {"content-length" "42", "content-type" "text/plain; charset=utf-8", "date" "Thu, 27 Jun 2024 07:22:52 GMT", "x-content-type-options" "nosniff"}, :uri #object[java.net.URI 0x34c72c31 ""], :request {:headers {:accept "*/*", :accept-encoding ["gzip" "deflate"], :user-agent "babashka.http-client/0.4.17"}, :throw false, :uri #object[java.net.URI 0x34c72c31 ""], :method :get}}

lread13:06:45

So @U03DKF57E0M, you have not provided any context which makes a bit tricky to try and help. But I see this type of thing from a bb nrepl session from cider. For example, if I start a nrepl server like so:

$ bb nrepl-server
Started nREPL server at 127.0.0.1:1667
For more info visit: 
And then from emacs, if I cider connect to this repl server. And then if I evaluate for example:
{:a 1 :b 2}
And then I cider inspect the result, in the cider inspect window I see:
Inspector error for: {:a 1, :b 2}
Is that the kind of thing you are doing?

borkdude14:06:21

Seems like a CIDER issue to me then?

lread14:06:43

I don't know the source of the error, if I try the same from a Clojure nrepl session, the cider inspect window works without error.

borkdude14:06:27

my suspicion is that something in CIDER broke bb-compatibility because it's assumed something is present (in the JVM process) that's not there (in bb).

borkdude14:06:47

but of course an issue with CIDER with a repro would be the best

lread14:06:02

For whatever reason, I never expected this to work and just fire up a Clojure nrepl if I want to use the inspector. But I can help out by raising an issue. I think this would be the right repo? https://github.com/clojure-emacs/cider-nrepl

borkdude14:06:11

oh sorry, you were using cider inspect. yeah, that doesn't work. sorry for the ping vemv!

lread14:06:03

So expected behaviour? No issue needed?

borkdude14:06:24

yes, at least, if cider-inspect is explicitly used

👍 1
vemv14:06:07

I reckon that the inspect middleware is unimplemented in bb. Might be low-to-medium-hanging fruit 🍏

borkdude14:06:47

I think it would be better if nrepl + cider could more or less run as is with bb instead of being a bespoke built-in thing. I had a brief stab at this once but didn't go too far with it. maybe one day...

👍 1
lread14:06:50

So @U03DKF57E0M, if you want to inspect data during babashka development, you might instead try: • using a Clojure nrepl session, you can discover bb built-in deps classpath via bb print-deps --format classpath • using https://github.com/djblue/portal (I think it supports bb?)

borkdude14:06:14

yes, for portal see the discussion in this channel prior to this one, towards the end

borkdude14:06:20

but yeah, the Clojure JVM tooling moves faster than bb can keep up with and is of higher quality, so for non-fast startup/dev purposes it's probably better to just use that + write tests that can be run with bb

borkdude14:06:41

this is where bb print-deps comes in as @UE21H2HHD has noted

vemv14:06:42

> I think it would be better if nrepl + cider could more or less run as is with bb instead of being a bespoke built-in thing. I had a brief stab at this once but didn't go too far with it. maybe one day... Most likely we'd be happy to receive :bb reader conditionals in the cider-nrepl codebase, and also alternative patterns supporting the distinct approach to middleware

borkdude14:06:33

maybe a nice summer project :)

M3tti19:06:32

wow so much text i have to get through it first. But wanted to let you know that i found the root cause i guess from the error. What i was doing was accessing the kubernetes api through a kubectl proxy. Somehow babashka http-client sets the connection upgrade header which leads in kubectl to an error. Not sure yet in detail why thats the case but it is related to proxing. You can have the same issue with kubctl proxy and nginx afaik. So what i did in the meanwhile is to use httpkit client which worked right from the start.

borkdude14:06:34

@U03DKF57E0M Could it be that you ran into a similar issue as https://github.com/babashka/http-client/issues/57 bb.http-client uses http2 as default (this behavior is from java.net.http) while curl/httpkit etc use http1 as default.

lread15:06:49

@U03DKF57E0M I still find your question too vague. We guessed you were wondering why you got an Inspector error, but maybe you were wondering why you got a 500 response?

👍 1
M3tti12:07:35

The issue was really in that http2 upgrade. No clue yet why this happens with babashka.http-client but that was the issue. i switched to httpkit client and everything works as expected. Thanx @U04V15CAJ for the link.

borkdude13:07:14

"No clue why that happens with bb.http-client": because this is just the default of the java.net.http client

M3tti13:07:39

@UE21H2HHD sorry for getting my question wrong but the issue wasn't about the inspector but by getting the 500 back from the kubernetes proxy which needs upgrades connections to http2.

👍 1
M3tti13:07:49

@U04V15CAJ got it now thanx

M3tti13:07:57

nice thanx