This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-13
Channels
- # adventofcode (35)
- # announcements (2)
- # arachne (1)
- # beginners (71)
- # chestnut (2)
- # cider (100)
- # cljdoc (17)
- # cljs-dev (17)
- # cljsjs (2)
- # cljsrn (2)
- # clojure (53)
- # clojure-austin (2)
- # clojure-europe (1)
- # clojure-finland (2)
- # clojure-italy (3)
- # clojure-nl (7)
- # clojure-russia (56)
- # clojure-spec (56)
- # clojure-uk (35)
- # clojurescript (58)
- # community-development (14)
- # core-async (9)
- # cursive (22)
- # data-science (5)
- # datomic (14)
- # duct (5)
- # emacs (2)
- # expound (4)
- # figwheel-main (6)
- # fulcro (23)
- # kaocha (8)
- # lumo (7)
- # off-topic (10)
- # pathom (6)
- # re-frame (17)
- # reitit (31)
- # ring (3)
- # rum (1)
- # shadow-cljs (45)
- # spacemacs (10)
- # sql (12)
- # testing (9)
- # tools-deps (130)
does the Clojure runtime have access to the aliases that were passed? Can my code access this information somehow?
I’d like to know whether its a figwheel run or not
@stathissideris everyone is going to name their Figwheel alias differently. I'd check if the namespace is loaded/can be required, and depending on context, check if the state var is bound.
good point about about naming, but I need this for my specific setup, I’m not making a generic tool, so hardcoding it would be ok
Is is possible to combine -e
and -m
to inject a var maybe?
oh thanks, I’ll check it out
I think there's a NPE in t.d.a:
Error building classpath. nil
java.lang.NullPointerException
at clojure.tools.deps.alpha.extensions.maven$eval638$fn__641.invoke(maven.clj:41)
at clojure.lang.MultiFn.invoke(MultiFn.java:239)
at clojure.tools.deps.alpha$canonicalize_deps$fn__1027.invoke(alpha.clj:74)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:343)
at clojure.core$reduce.invokeStatic(core.clj:6827)
at clojure.core$reduce.invoke(core.clj:6810)
at clojure.tools.deps.alpha$canonicalize_deps.invokeStatic(alpha.clj:73)
at clojure.tools.deps.alpha$canonicalize_deps.invoke(alpha.clj:71)
at clojure.tools.deps.alpha$expand_deps.invokeStatic(alpha.clj:189)
at clojure.tools.deps.alpha$expand_deps.invoke(alpha.clj:170)
at clojure.tools.deps.alpha$resolve_deps.invokeStatic(alpha.clj:236)
at clojure.tools.deps.alpha$resolve_deps.invoke(alpha.clj:218)
at clojure.tools.deps.alpha.script.make_classpath$create_classpath.invokeStatic(make_classpath.clj:59)
at clojure.tools.deps.alpha.script.make_classpath$create_classpath.invoke(make_classpath.clj:52)
at clojure.tools.deps.alpha.script.make_classpath$run.invokeStatic(make_classpath.clj:70)
at clojure.tools.deps.alpha.script.make_classpath$run.invoke(make_classpath.clj:64)
at clojure.tools.deps.alpha.script.make_classpath$_main.invokeStatic(make_classpath.clj:109)
at clojure.tools.deps.alpha.script.make_classpath$_main.doInvoke(make_classpath.clj:84)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.core$apply.invokeStatic(core.clj:665)
at clojure.main$main_opt.invokeStatic(main.clj:491)
at clojure.main$main_opt.invoke(main.clj:487)
at clojure.main$main.invokeStatic(main.clj:598)
at clojure.main$main.doInvoke(main.clj:561)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.main.main(main.java:37)
this may be time sensitive as I'm using a just-deployed coordinate.org.webjars.bower/react {:mvn/version "15.4.2"}
org.webjars.bower/es6-promise {:mvn/version "4.0.5"}
org.webjars.bower/fetch {:mvn/version "0.9.0"}
org.webjars.bower/graphiql {:mvn/version "0.11.11"}
org.webjars.npm/graphiql-subscriptions-fetcher {:mvn/version "0.0.2"}
org.webjars.npm/subscriptions-transport-ws {:mvn/version "0.8.3"}
these are the deps I just added org.webjars.npm/graphiql-subscriptions-fetcher {:mvn/version "0.0.2"}
this appears to be the exact problem dep
runtime does not have access to the aliases that were used @stathissideris
@alexmiller thanks, I ended up using -D to indicate the alias via properties as @dominicm suggested
I can repro the npe, will take a look. shouldn’t be timing-related
there’s a version range in the transitive deps, wouldn’t surprise me if that’s involved
that seems more likely, yeah. I was worried that we'd caught maven in an inbetween state and it was causing an NPE.
I think it’s finding no matches in the version range
so code could definitely be tightened up around that to not npe but it will just not find the dep then
org.webjars.npm/graphiql-subscriptions-fetcher {:mvn/version "0.0.2"}
depends on org.webjars.npm/graphql {:mvn/version "[0.9.1,0.10)"
but I don’t see anything older than 0.10.1 in maven central
I’ll fix the npe
webjars is a bit weird. You basically are deploying npm things. So if nobody has deployed graphiql 0.10, then it won't be there.
adding an explicit graphiql dep hasn't helped though, annoyingly. So I guess I will deploy 0.10 via http://webjars.org
does npm actually have jars in it?
tdeps could have an extension to use webjars directly
well, you would need to tell me more things for me to understand what’s possible, but anything that can be a source of named, versioned artifacts is a potential target
well, webjars seems to have a a cdn? whatever step you’re doing seems like some sort of mindless wrapping task
programs are good at those
> All of the WebJar contents are available on the public jsDelivr CDN. Just prefix //cdn.jsdelivr.net/webjars/{groupId} in front of your static asset URLs. For instance, if using the org.webjars : jquery WebJar and your local URL to jquery.js is /webjars/jquery/2.1.0/jquery.js then the CDN URL would be: //cdn.jsdelivr.net/webjars/org.webjars/jquery/2.1.0/jquery.js So I guess the contents of the jars are available via the CDN, rather than the jars themselves.
then you can request a new jar to go to maven via clicking buttons on http://webjars.org - that triggers an automated process
“clicking buttons” :)
is your proposal that instead of deploying to maven, a webjars-like thing would build the jars and stick them in ~/.local/cache/webjars/foo.bar.1.jar ?
why do you even need jars? they’re just files on the classpath right?
it would be helpful to do something that actually helped people down the line as they build and deploy stuff
I am too ignorant about cljs / npm / node / etc to not know what would be useful
npm is a central repository. it has stuff you want in your app. tools.deps has an extension point to plug in code to get stuff and put it on your classpath (and determine its dependencies)
see how ignorant I am? :)
yeah, anything that didn’t come out this month in js is old :)
I guess coming back to a problem statement - this is like js stuff that you want to serve as static resources from your app?
does npm really not have any kind of namespacing?
oh, it has scopes, I see
well, seems like the info necessary exists if you want to file a ticket defining what’s useful
> I guess coming back to a problem statement - this is like js stuff that you want to serve as static resources from your app? Exactly!
bower predates npm afaik. It was a big step forward at the time, but it's not really used. npm got more traction and was dominant by the time a majority of companies turned their attention to js.
I'll write down that I want to create this, and have a note for myself to think a little more about what I want 🙂
@alexmiller while I have you, is there a workaround for this graphiql issue? bintray appears to be having issues, and I can't get an older graphiql to deploy. :exclusions
hasn't worked, nor has an explicit graphiql dependency on 0.11.11.
not sure I have a good option for you
if you made webjars deploy version 0.9.1 to maven central that would let it proceed
kind of an interesting failure mode. would be better if it could defer long enough to be overridden
in this particular case, the only reason it’s resolving early is due to the version range I think, trying to narrow that down to single version
Hmm, 0.9.1 now exists, but I'm still seeing a NPE. no it doesn't, i've been deploying the wrong package
You hit an NPE whenever you have a transitive dependency which doesn't exist. I'm seeing it with a version pinned to [1.0.3]
(maybe that is a range though?)
https://search.maven.org/artifact/org.webjars.npm/graphql/0.9.1/jar depends on https://search.maven.org/artifact/org.webjars.npm/iterall/1.0.3/jar but I'm still hitting the exact same NPE.
❯ clj -Sdeps '{:deps {org.webjars.npm/graphql {:mvn/version "0.9.1"}} :aliases {:v {:verbose true}}}' -A:v -Sforce
Initial deps to expand:
{org.clojure/clojure #:mvn{:version "1.10.0"},
org.webjars.npm/graphql #:mvn{:version "0.9.1"}}
Expanding org.clojure/clojure #:mvn{:version 1.10.0}
=> include, pin top dep
Expanding org.webjars.npm/graphql #:mvn{:version 0.9.1}
Error building classpath. nil
java.lang.NullPointerException
at clojure.tools.deps.alpha.extensions.maven$eval638$fn__641.invoke(maven.clj:41)
[ERROR] Failed to execute goal on project my-app: Could not resolve dependencies for project
maven is struggling too
Oh. Interesting. It is fine with it as a top-level dependency, but not as a transitive dep.
[1.0.3] is a version range. from Maven’s perspective just 1.0.3 by itself is a specific version
I don’t think there’s any difference with top vs transitive - you probably just have it in your local Maven repo at ~/.m2/repository now
it works for me as a transitive dep, and as a top-level dep with specific version, and as a top-level dep with version range [1.0.3]
(clearing all caches before each one)
$ rm -rf ~/.m2/repository/org/webjars
$ clj -Sdeps '{:deps {org.webjars.npm/graphql {:mvn/version "0.9.1"}}}' -Sforce
Downloading: org/webjars/npm/graphql/0.9.1/graphql-0.9.1.pom from
Downloading: org/webjars/npm/iterall/maven-metadata.xml from
Downloading: org/webjars/npm/iterall/1.0.3/iterall-1.0.3.pom from
Downloading: org/webjars/npm/graphql/0.9.1/graphql-0.9.1.jar from
Downloading: org/webjars/npm/iterall/1.0.3/iterall-1.0.3.jar from
Clojure 1.10.0
user=>
when you deploy to Maven central it can take 10 minutes to an hour to show up for download, so maybe it just wasn’t there yet
I'm a bit suspicious that perhaps version ranges are searched somewhere different than specific versions.
they aren’t
but there is an extra piece of code to explicitly resolve them in tdeps
if you haven’t, you should try selectively deleting part of your ~/.m2/repository/org/webjars/…
there are metadata files about versions that are cached there and only updated once every 24 hrs
(this is a setting we don’t currently surface - if you’re using mvn, you can pass -U to force an update)
it just stores known versions and then uses that to resolve
but if you had already filled that cache for the day and the repository said that version didn’t exist, it’s going to keep telling you that
it will not go re-check the repository
this file in particular: ~/.m2/repository/org/webjars/npm/iterall/maven-metadata-central.xml
last check timestamps are in ~/.m2/repository/org/webjars/npm/iterall/resolver-status.properties
@alexmiller on the slow REPL startup of the latest java 8 (u202) on Linux, looking at the stack traces, it spends a lot of time compiling some java-time things (https://github.com/dm3/clojure.java-time). One CPU goes to 100% during this and after that stack trace is gone, the REPL starts.
java-time does lot of meta programming stuff, finding types, doing a graph traversal to find paths between types
blugh, after all this work, one of my transitive deps doesn't work because it has a custom gql license which webjars won't automatically repackage because it doesn't recognize. If we were a direct npm client this would be avoided. Very tempting proposition really.
@alexmiller if I wrote an npm client with an EPL license in clojure, would it be candidate for use in t.d.a? Or would you prefer it was under the clojure/core umbrella?
could be an external lib (we use others already). I think there are some out there already. but maybe the amount of access needed by tda is so small to not even be worth that, not sure.
I guess you probably want a cache ala tools.gitlibs though and that’s something we’d want outside tda
I haven't really looked at the npm client details yet. Might be worth seeing if we can share the yarn cache. Plus I'm a bit uncertain about how to handle http.
well I think you have the same options as gitlibs - shell out to npm or make a direct implementation
pros and cons. might be worth gathering some more information about the things you need to implement: 1) given a name/version, determine that lib’s deps (don’t need transitive, just shallow) 2) given a name/version, download the bits somewhere
Npm is far more amenable I think. Yarn is a reimplementation of the npm client. Plus, npm doesn't have a global cache, and because of the hierarchical nature, you probably want more control.
well public stuff is fine I assume
for creds, we already have a means to do this via the maven settings.xml on a per-repo basis
admittedly kind of weird to put npm auth there
@hiredman, the weird thing is that it's only a minor version upgrade (from 8.u192 to 8.u202). With 192 the repl starts in seconds, with 202 it takes minutes
I know it's aside from your problem @stijn but I wouldn't use that library, to be perfectly honest.
https://juxt.pro/tick/docs/index.html makes java.time quite nice, and it works in cljs :face_with_rolling_eyes: (I work for JUXT)
That's a matter of opinion @U050ECB92 🙂 I find clojure.java-time
really does produce cleaner-looking code in a lot of situations.
It's a one-off cost, the first time you use certain constructors. It's fast after that.
The readme even shows how you can "warm up" that stuff.
I was a bit surprised that it caused such a "blip" on 202(?) since it's fine on 192 (and on subsequent builds) according to the OP.
maybe check to see if you have org.threeten.extra.Temporals and or org.joda.time.DateTime on your classpath, and if calling (Class/forName ...) with those class names changes behavior on the different jdk versions
tools.deps.alpha 0.6.488 and clj 1.10.0.414 now available - https://groups.google.com/forum/#!topic/clojure/5EWvlgC4C9U
just a couple small enhancements, no biggie
hadn’t released in a while
That Groups post hasn't gone out via email again, as far as I can see @alexmiller
(I just replied to it on the web which should cause it to be seen via email 🙂 )
I sent that one from a different account