This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-06
Channels
- # babashka (62)
- # beginners (52)
- # calva (37)
- # clj-kondo (23)
- # cljs-dev (13)
- # clojure (18)
- # clojure-europe (7)
- # clojure-sg (1)
- # clojure-spec (27)
- # clojurescript (37)
- # datomic (14)
- # events (2)
- # fulcro (9)
- # graalvm (12)
- # helix (1)
- # introduce-yourself (1)
- # keyboards (3)
- # lsp (3)
- # missionary (24)
- # nextjournal (7)
- # pedestal (3)
- # polylith (15)
- # re-frame (5)
- # reitit (4)
- # releases (2)
- # shadow-cljs (54)
- # testing (7)
- # uncomplicate (4)
Looks like the first thing it complains about is clojure.tools.deps.alpha.util.concurrent
It imports java.util.concurrent Callable Future ThreadFactory ExecutorService Executors TimeUnit
@U0HFRSY0M Some parts of tools.build can run with babashka. But tools.deps.alpha itself doesn't because of the dependency on all kinds of maven and aws stuff. Often functions in tools.build receive a basis as argument which means it doesn't have to call tools.deps.alpha anymore since all the info is already in the basis. If we can set things up in such a way that for the basis, we can shell out to a JVM and for the rest we can use babashka, then it can work, but tools.build itself isn't organized in this way.
Last time I tried there were a couple of classes missing in bb. I'd be happy to add those if this approach is promising.
My aim was to speed up running tools.build invocations. If we’re starting the JVM to get the basis, then its probably just as fast to run everything in the jvm. One possibility might be to use the cached classpath, if available, and only invoke the JVM to recompute it. Not sure if that is feasible or not.
> If we’re starting the JVM to get the basis, then its probably just as fast to run everything in the jvm. Indeed. This is what I figured too.
I think it might be possible to build a tools.build pod at one point though. I have an experimental version of tools.deps.alpha compiled to native.
@U0HFRSY0M I did use fs/modified-since
in some projects to not invoke a JVM when not necessary
I blogged about that here: https://blog.michielborkent.nl/speeding-up-builds-fs-modified-since.html
I think it is possible to make a fork of tools.build to strip out tools.deps.alpha and only include JVM standard lib classes to make it bb compatible
but using this native tools deps alpha thing, you could then calculate the basis using that
A tools.deps.alpha pod would be awesome, and would probably greatly simplify getting tools,build to work.
you would run into issues when you try to include more libraries like https://github.com/slipset/deps-deploy/blob/master/src/deps_deploy/deps_deploy.clj though
Isn’t that just a case of needing to build the relevant message parser in tools-deps-native?
@U0HFRSY0M you mean, to turn it into a pod?
I mean, if you would use deps-deploy in your build scripts, to deploy to clojars. this wouldn't work with babashka. so in general you couldn't replace all of your build needs with the pod probably is what I'm saying.
Ah, indeed, but there may be ways of getting round that (e.g. I have a deploy task that only use the maven metadata dependency, and works over http)
I think the shortest path to a POC is to alter the tools-deps-native binary to receive the args of create-basis as EDN and print out a basis as EDN instead of a classpath.
Then this can be used to shell out to in a function create-basis which you can use within bb
e.g. in clj-kondo: https://github.com/clj-kondo/clj-kondo/blob/dd70577b7ce278665b02afa5387990d172002264/src/clj_kondo/main.clj#L112
@U0HFRSY0M I'm trying to use the pod + making bb more compatible with tools.build.
This script now works with the tools-build
branch of bb.
#!/usr/bin/env bb
(ns foo)
(require '[babashka.pods :as pods])
(pods/load-pod "./tools-deps-native")
(require '[babashka.deps :as deps])
(deps/add-deps '{:deps {borkdude/spartan.spec {:git/url ""
:sha "12947185b4f8b8ff8ee3bc0f19c98dbde54d4c90"}
io.github.clojure/tools.build {:tag "v0.6.2" :sha "226fb52"}}})
(require '[spartan.spec])
(require '[clojure.tools.build.api :as b])
(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def jar-file (format "target/%s-%s.jar" (name lib) version))
(defn clean [_]
(b/delete {:path "target"}))
(require 'clojure.tools.build.tasks.copy)
(defn jar [_]
#_(b/write-pom {:class-dir class-dir
:lib lib
:version version
:basis basis
:src-dirs ["src"]})
(b/copy-dir {:src-dirs ["src"]
:target-dir class-dir})
(b/jar {:class-dir class-dir
:jar-file jar-file}))
(jar nil)
The write-pom
needs more work since a couple of things from clojure.data.xml
aren't there in bb yet. But we can iterate on this.
Another option would be to make the tools-deps-alpha
pod a tools-build
pod so we move everything there.
I don’t think anything in these namespaces is going to be used in a tight loop, so may not be worth getting into bb itself. We could make it a clojure tools pod.
@U0HFRSY0M I added some stuff in tools-build
branch and so far it caused only very minor increase in binary size.
I have yet to add the extra clojure.data.xml
namespaces to make write-pom compatible
With the tools-build
https://github.com/babashka/babashka/commit/bc0943f45dd06308099eb0f3a5b2a86598c6175d bb I get , Unable to resolve classname: javax.xml.namespace.NamespaceContext
when running the jar task
Would it be worth adding a real babashka.deps
namespace? It would only implement what actually works in the jvm version of clojure, so no add-deps
. I ask because it would be kinda dope to use my bb tasks with my existing jvm nrepl connection. I have a https://github.com/djblue/portal/commit/dc0c6ae9f0339e79b08072207e511da27e55ea5b#diff-8b9e9b3023c4ac2fa9d74f705f9b7e6ec82fce4552b9456e31e7d2ec563a00f0 for my project, but was wondering if something like this could live in bb.
@U1G869VNV Done on master. Use 0.6.5-SNAPSHOT to test
I’m so, so happy that I don’t have to write stuff like this in bash anymore, thank you @borkdude! 🙏 https://github.com/schmee/dotfiles/blob/master/install_zig.bb