This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-04
Channels
- # announcements (25)
- # babashka (7)
- # beginners (52)
- # calva (29)
- # clara (1)
- # clj-kondo (4)
- # cljs-dev (55)
- # clojure (86)
- # clojure-europe (5)
- # clojure-finland (1)
- # clojure-france (1)
- # clojure-italy (1)
- # clojure-nl (1)
- # clojure-uk (57)
- # clojurescript (33)
- # conjure (107)
- # cursive (20)
- # datomic (37)
- # emacs (23)
- # events (13)
- # fulcro (67)
- # helix (73)
- # jobs-discuss (22)
- # lambdaisland (1)
- # leiningen (32)
- # malli (2)
- # meander (9)
- # mid-cities-meetup (1)
- # observability (1)
- # off-topic (14)
- # overtone (3)
- # pathom (39)
- # re-frame (22)
- # reagent (13)
- # reitit (13)
- # shadow-cljs (52)
- # sql (15)
- # tools-deps (29)
- # vim (11)
try using -Sforce
that will force the classpath to be recomputed, not used from cache and should trigger a download
@alexmiller Thanks! it works
Is there a way to run the clj/clojure script so it doesn't try to resolve deps first? were getting a classpath error and were hoping to get some diagnostic information via J-XshowSettings:properties, but we hit the "cannot find artifact" error first.
if you don't resolve deps, you can't make a classpath, and thus can't start a JVM to use that setting, so no?
That makes sense. I guess i need to oreint myself, clj assumes you can start a JVM, but for debugging their is some information you can get before that. So i can just run java -XshowSettings:properties.
is that a thing?
is what a thing? 🙂
showsettings
I see it is - was confused by the help message after nvm
If a deps procurer (local/root) points to another deps with a Procurer (e.g mvn/repos) Can i assume that it will read that Procurer or does it just grab the deps?
if you're asking whether transitive dependency maven repos will be used to resolve dependencies, then no
maven allows this, but it seems awfully dicey from a security pov so I kind of consider it an anti-feature
its likely i'm not describing this correctly. I have a deps.edn with {:deps {datomic {:local/root "../datomic"}} and in "../datomic" the deps reads {:mvn/repos {"http://my.datomic.com" {:url "https..."}} It seems i have to add the mvn repos to the deps with the local/root procurer, even though that deps doesn't directly have a dep on datomic-pro. It has that dependency through the other deps. @alexmiller as always, thanks for the help.
Yeah, that’s the scenario I’m describing
The question is, do you want your transitive deps to make decisions about where you get things on the internet?
The answer is definitely not an unqualified yes
So it needs a lot of thought
i understand. thanks alex.
okay, I know how to bait Alex Miller to tell us some more about tools-build, watch this:
do you want me to write about it, or do you want me to finish it? :)
I was going to make a joke reply, but now I'm trying to decide my actual stance on it... If I know the high level goal I can plan around it and start getting my chickens in a row 🐔
@dominicm I'm curious how your chickens would be organized differently based on various possible high level goals of tools.build
?
Anyway. I usually find libraries from core require a shift in thinking or approach. Eg clj forces you to do your own builds, so I'd expect the ecosystem to start building -mains earlier in anticipation. I have done my best to make sure my build functions can be used in different ways, but I'm betting I missed something. Knowing whether it solves the java sources problem would allow people using lein currently who want to move off to start doing any prep they need, as I doubt there will be something as straightforward as :java-sources.
I'm not sure what "prep" those lein
users could realistically do, even if the goal was stated as "solves the java sources problem"?
If tools.build
can completely replace depstar
, I'll be happy to switch to it. That means: build JAR and uberJAR, do AOT, specify the main namespace, Multi-Release JAR support, merging data readers (and several other types of files) in appropriate ways... If it also includes Java compilation, I might change how we build/deploy a couple of OSS Java projects that we currently build from source (manually, as needed) and use local JAR files for.