Fork me on GitHub
#babashka
<
2023-03-27
>
greg07:03:26

Hi, I experience error saying:

Error building classpath. Unable to compare versions for com.fulcrologic/fulcro-i18n: {:mvn/version "1.0.0", :deps/manifest :mvn} and {:git/url "", :git/sha "72f8cbba597de574480ae21322180f0590213e06", :deps/manifest :deps, :deps/root "/home/user/.gitlibs/libs/com.fulcrologic/fulcro-i18n/72f8cbba597de574480ae21322180f0590213e06"}
Here is a minimal repo reproducing the problem: https://github.com/rynkowsg/bb-deps-versions-error

borkdude08:03:48

Looking now

borkdude08:03:10

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

borkdude08:03:25

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

borkdude08:03:04

You would get the same error with clj

greg09:03:20

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

borkdude09:03:30

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

borkdude09:03:41

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

greg09:03:35

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

borkdude09:03:07

You can discuss this is in #C6QH853H8

greg09:03:18

I posted the same question on tools.deps. Thanks for answer. At least I know it is not babashka πŸ™‚

πŸ‘ 2
grav09:03:09

(Offtopic?) Just tried upgrading jet - there's no linux-aarch build, and the install script gave me an AMD64 version.

grav09:03:10

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
Can anyone supply an Aarch binary? πŸ™‚

borkdude09:03:20

you mean for linux?

grav09:03:29

Yes, sorry

borkdude09:03:34

feel free to post an issue

πŸ‘ 2
borkdude09:03:54

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

grav09:03:12

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

grav09:03:27

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

borkdude09:03:06

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

πŸ‘ 2
grav09:03:13

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?

grav09:03:35

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

borkdude09:03:39

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

borkdude09:03:49

(except brew, I maintain myself)

πŸ‘ 4
grav09:03:11

Never maintained before, but I'll consider πŸ‘

borkdude09:03:26

what hardware are you running?

grav09:03:41

A Macbook M1 with a Linux VM

grav09:03:49

Running in Parallels

grav09:03:04

Yes, it's awesome. Best of both worlds. Eg Bluetooth headset actually working πŸ˜‰

borkdude09:03:27

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

πŸ‘ 2
borkdude09:03:46

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

πŸ‘ 2
borkdude09:03:42

For those who are using aarch64 binaries for babashka on linux / android, can you test whether the "static" or non-static works for you? I am considering dropping one of both builds and since I have to create a new one for #jet I'd like to know which one works best. cc @grav 🧡

borkdude09:03:49

Please respond in thread

borkdude09:03:53

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

grav11:03:44

@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.

πŸ‘ 1
Tomas Brejla13:03:12

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

Tomas Brejla13:03:34

Static that is

borkdude13:03:44

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

πŸ‘ 2
borkdude18:03:35

This is a common question and bbin is the common answer: https://github.com/babashka/babashka/discussions/1525 Still, projects like node.js resolve dependencies relative to the invoked script. E.g.

$project/script.js
$project/package.json
# assume $project is on PATH
other_dir $ script.js # picks up dependencies from $project/package.json
I think we could do the same with babashka: the --config would default to the relative bb.edn of the invoked script, unless the script is in a subdirectory of the current working directory and the current working directory already has a bb.edn What could go wrong?

πŸ‘€ 2
teodorlu13:03:10

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

borkdude13:03:38

No

πŸ‘ 2
teodorlu13:03:59

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

borkdude13:03:50

what exactly is your question?

borkdude13:03:11

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

borkdude13:03:43

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

borkdude13:03:54

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

πŸ‘ 2
teodorlu20:03:01

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 πŸ˜…

joakimen11:03:45

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)

πŸ‘ 2