This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-27
Channels
- # announcements (2)
- # architecture (1)
- # aws (3)
- # babashka (50)
- # beginners (99)
- # biff (7)
- # calva (11)
- # clj-http (1)
- # clj-kondo (18)
- # cljs-dev (17)
- # clojars (33)
- # clojure (63)
- # clojure-europe (83)
- # clojure-nl (2)
- # clojure-norway (4)
- # clojure-sweden (18)
- # clojure-uk (2)
- # clojurescript (7)
- # datalevin (3)
- # docker (2)
- # emacs (44)
- # malli (10)
- # music (2)
- # off-topic (2)
- # portal (4)
- # practicalli (2)
- # reagent (23)
- # reitit (6)
- # shadow-cljs (22)
- # spacemacs (8)
- # sql (35)
- # tools-deps (2)
- # xtdb (5)
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-errorok, I see. I wonder what can I do here with it other then adding couple of :exclusions in mvn deps
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
I posted the same question on tools.deps. Thanks for answer. At least I know it is not babashka π
(Offtopic?)
Just tried upgrading jet
- there's no linux-aarch build, and the install script gave me an AMD64 version.
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? πbut if your previous jet worked, the newer should also work, since there was no aarch64 linux binary
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?
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 π§΅
@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
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?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
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)