Looking now

Oh yes, this is just a deps.edn problem, not specific to babashka

You can't compare versions between mvn and git so that is what it complains about

You would get the same error with clj

ok, I see. I wonder what can I do here with it other then adding couple of :exclusions in mvn deps

or you can include a specific version of i18n on the top level

then it won't compare versions, it will pick the top level one

Yeah, but then it would mean I will include lets say i18n, fulcro, rad and all the libs that can not be compared despite I don't need them

You can discuss this is in #C6QH853H8

I posted the same question on tools.deps. Thanks for answer. At least I know it is not babashka 🙂

I tried script/compile in the repo, but it seems my graalvm is broken:

Error occurred during initialization of boot layer
java.lang.module.ResolutionException: Module org.graalvm.nativeimage.builder contains package com.oracle.svm.core.annotate, module org.graalvm.sdk exports package com.oracle.svm.core.annotate to org.graalvm.nativeimage.builder
Error: Image build request failed with exit status 1

you mean for linux?

Yes, sorry

feel free to post an issue

but if your previous jet worked, the newer should also work, since there was no aarch64 linux binary

I think at that time I managed to compile it myself, but I forget.

I might have subsequently broken my graalvm install since I rarely use it

this is the version used on CI: /home/circleci/graalvm-ce-java11-22.3.0 22.3.1 should also work

I'll post an issue - would be awesome to have pre-build binaries. Do you already distribute some binaries via https://wiki.archlinux.org/title/Arch_User_Repository?

(Arch Linux is as far as I know the most mature aarch64 linux dist)

I'm not maintaining package managers myself but you're welcome to do it

(except brew, I maintain myself)

Never maintained before, but I'll consider 👍

what hardware are you running?

A Macbook M1 with a Linux VM

ah nice

Running in Parallels

Yes, it's awesome. Best of both worlds. Eg Bluetooth headset actually working 😉

ok, the issue is welcome, I'll probably do this at the end of this week

There is also a #CM5HRADAA channel, let's continue there

Please respond in thread

@U01LFP3LA6P I think you were also using this at some point, right?

@U04V15CAJ Just checked, I'm using whatever https://aur.archlinux.org/packages/babashka-bin is using, which (if I'm parsing the PKGBUILD correctly) is the static build.

Using that url from grav, bb 1.3.176 aarch64 works fine on my android tablet

Static that is

ok, I think I'll drop support for the non-static then. All the pods are also using the static option

🧵

Does #C6QH853H8 do this in a way we can learn from?

No

I've asked myself variations of this question. I like getting help from #lsp and #clj-kondo, and I can get that if I structure my scripts as entrypoints to a "proper Clojure project". Not sure how LSP/clj-kondo would work for ad-hoc scripts. one clojure project, multiple CLI entrypoints: https://github.com/teodorlu/shed

what exactly is your question?

clj-kondo works for individual scripts if you set it up with flycheck-clj-kondo

I can't get lsp to work with individual scripts though.

but this is a different topic, let's move that in #CPABC1H61 or so

Yeah -- it was more a reflection on my own usage. I like having a "project" over individual files, and I like that #babashka-bbin can manage the installation. With that usage pattern, I don't really run into situations where I feel like I need what's being asked for. Which I realize doesn't answer your "What could go wrong?" question 😅

Without understanding the implications of the change, and if it’s a cheap experiment, I would like this. I’m in the opposite camp; I usually make lots of small scripts and few projects, since that is the gap that Babashka fills for me (in contrast to full-blown Clojure projects)