This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # beginners (90)
- # cider (15)
- # clara (1)
- # clj-kondo (2)
- # cljs-dev (17)
- # clojars (8)
- # clojure (132)
- # clojure-europe (14)
- # clojure-nl (5)
- # clojure-uk (57)
- # clojurescript (39)
- # code-reviews (44)
- # conjure (6)
- # core-async (6)
- # crux (3)
- # cursive (20)
- # data-science (1)
- # datomic (13)
- # fulcro (11)
- # graalvm (6)
- # graphql (6)
- # helix (10)
- # joker (2)
- # kaocha (37)
- # leiningen (24)
- # malli (15)
- # off-topic (13)
- # pathom (18)
- # pedestal (14)
- # re-frame (67)
- # reitit (5)
- # ring (13)
- # ring-swagger (4)
- # sci (41)
- # shadow-cljs (33)
- # slack-help (5)
- # spacemacs (1)
- # sql (34)
- # tools-deps (64)
- # vim (171)
Heya @alexmiller I'm reading through tools.deps and you're using some pretty advanced kung fu in there. I don't suppose in all your ample free time you've given any talks or write-ups on a deep dive there have you? I'm trying to write some clojurescript CLI tools for working with deps and trying to port some of the stuff. Also, I tried running with CIDER but nREPL on the deps ran into the predictable errors for including java classpaths -- I'm curious what your REPL technique is for developing tools.deps.alpha?
The last conj talk is probably the most detailed info about the impl. What part are you having trouble with? Re repl, I just open it in Cursive as a Maven project
Hmm, only the one from EuroClojure is https://www.youtube.com/watch?v=sStlTye-Kjk. But there's another one from the latest Conj.
I was there for the last one. I think I'm looking for more "how to contribute" style info
@goomba ClojureScript already has cljs.main which works great in tandem with tools.deps?
yeah of course. I'm not trying to replicate that functionality -- I'm working on something more like "pip for deps"
I've got it working for clojars but there's a bunch of stuff on git and maven and I don't know how to work with those yet
Has GraalVM gotten to the point where we can write arbitrary CLI stuff in Clojure now?
@goomba meta-example: https://github.com/borkdude/deps.clj
that is the
clojure bash script ported to both babashka and GraalVM, so you can either run it as script or binary
you can even babashka in powershell!? @borkdude your level of masochism is very impressive
well with covid I'm willing to wager most aren't even wearing pants. So I was just playing the odds
It looks like
find-deps , from a quick glance, is dealing with the same limitation I have
which is finding
reagent is easy but
org.clojure/core.async is not as easy
I'm not sure how to differentiate in Maven what is Clojure and what is Java, for instance, conceptually
or... maybe it doesn't matter -- as I say it out loud. That's kind of the point of Clojure, isn't it? 😆
If you’re talking about searching/finding deps, we’ve actually done some thinking about this in tandem with add-lib and I’ve even prototyped some of it in the add-lib2 branch of tools.deps but it’s not in a usable state right now
Is there a good commit on the
add-lib2 branch that can be checked out and played around with?
I'm thinking of adding a filewatcher on
deps.edn and just automatically add any new libraries that are added there without having to restart the repl.
I have an example in my
dot-clojure repo that I use all the time -- but @alexmiller has cautioned that
add-lib will probably break as code moves around
hey @aviflax did you ever get a tools dep answer for tar.gz files ending up on your classpath? https://github.com/oracle/graal/issues/2481
The comment on that issue from
olpaw to the effect that the tar.gz file shouldn’t have been included in the classpath in the first place made sense to me.
So I thought maybe this might be one of those places wherein tools.deps is deviating from commonly assumed Maven behavior/convention
Yeah, I bet @alexmiller knows! Here’s the dep that brings in tar.gz files: https://github.com/FundingCircle/repro-graalvm-mac-issue/blob/83abc805467808221cf48108f735527e3e3de9fa/deps.edn#L3
I guess this does not happen with leiningen, as @borkdude references it from babashka project.clj https://github.com/borkdude/babashka/blob/e667bb5d2f344fdfd12ce12639c768d80e252138/project.clj#L57
As I mentioned in that graal issue, the tar.gz file comes from https://search.maven.org/artifact/org.graalvm.truffle/truffle-nfi/20.1.0/jar for org.graalvm.truffle/truffle-nfi 20.1.0:
<dependency> <groupId>org.graalvm.truffle</groupId> <artifactId>truffle-nfi-native-linux-amd64</artifactId> <version>20.1.0</version> <type>tar.gz</type> </dependency>
I assume must be some use case for including such a file in a pom, although I have no idea what it is. And I assume that Maven, and whatever mechanism Leiningen uses to work with Maven, somehow filters these files out when/where they’re not needed/useful.
That’s a native dep and there is a facility in Maven to support loading those for the jvm
That Linux and amd64 there are actually parsed and used to select the right native dep for the os/arch