This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-08
Channels
- # announcements (5)
- # babashka (46)
- # beginners (32)
- # calva (9)
- # chlorine-clover (4)
- # clojars (31)
- # clojure (83)
- # clojure-italy (1)
- # clojure-nl (1)
- # clojure-spec (13)
- # clojure-uk (12)
- # clojuredesign-podcast (1)
- # clojurescript (30)
- # cursive (3)
- # fulcro (18)
- # graalvm (6)
- # graphql (2)
- # jobs-discuss (6)
- # joker (4)
- # malli (1)
- # nrepl (1)
- # off-topic (15)
- # shadow-cljs (2)
- # spacemacs (3)
- # tree-sitter (19)
- # vim (1)
- # vscode (7)
anything wrong with clojars? tried to publish my package usual way via “lein deploy clojars” and got this
and there goes my hour: https://github.com/technomancy/leiningen/issues/2664
the release seems to be corrupted on clojars: https://clojars.org/binaryage/dirac/versions/1.5.8
but clojure -Srepro -Sdeps '{:deps {binaryage/dirac {:mvn/version "1.5.8"} org.clojure/clojurescript {:mvn/version "RELEASE"} clj-logging-config {:mvn/version "1.9.12"}}}' -m dirac.main
is giving me Error building classpath. Could not find artifact binaryage:dirac:jar:1.5.8 in central (
I’m unable to diagnose this further. deps.edn should be using clojars.
I don't know what's going on with lein and checksums, but for this particular issue, 1.5.8 downloads fine for me:
$ clojure -Srepro -Sdeps '{:deps {binaryage/dirac {:mvn/version "1.5.8"} org.clojure/clojurescript {:mvn/version "RELEASE"} clj-logging-config {:mvn/version "1.9.12"}}}' -m dirac.main
Downloading: org/clojure/clojurescript/maven-metadata.xml from
Downloading: binaryage/dirac/1.5.8/dirac-1.5.8.pom from
Downloading: org/clojure/clojurescript/1.10.597/clojurescript-1.10.597.pom from
Downloading: clj-logging-config/clj-logging-config/1.9.12/clj-logging-config-1.9.12.pom from
Downloading: org/clojure/core.async/1.0.567/core.async-1.0.567.pom from
Downloading: org/clojure/tools.logging/1.0.0/tools.logging-1.0.0.pom from
Downloading: org/clojure/tools.cli/1.0.194/tools.cli-1.0.194.pom from
Downloading: org/clojure/pom.contrib/1.0.0/pom.contrib-1.0.0.pom from
Downloading: funcool/cuerdas/2.2.1/cuerdas-2.2.1.pom from
Downloading: com/rpl/specter/1.1.3/specter-1.1.3.pom from
Downloading: me/raynes/conch/0.8.0/conch-0.8.0.pom from
Downloading: clj-sub-command/clj-sub-command/0.5.1/clj-sub-command-0.5.1.pom from
Downloading: ring/ring-defaults/0.3.2/ring-defaults-0.3.2.pom from
Downloading: binaryage/devtools/1.0.0/devtools-1.0.0.pom from
Downloading: org/clojure/tools.logging/0.2.6/tools.logging-0.2.6.pom from
Downloading: log4j/log4j/1.2.16/log4j-1.2.16.pom from
Downloading: org/clojure/tools.analyzer.jvm/0.7.3/tools.analyzer.jvm-0.7.3.pom from
Downloading: org/flatland/useful/0.10.6/useful-0.10.6.pom from
Downloading: org/clojure/tools.cli/0.4.1/tools.cli-0.4.1.pom from
Downloading: ring/ring-anti-forgery/1.3.0/ring-anti-forgery-1.3.0.pom from
Downloading: org/clojure/tools.analyzer/0.7.0/tools.analyzer-0.7.0.pom from
Downloading: org/clojure/tools.analyzer/0.7.0/tools.analyzer-0.7.0.jar from
Downloading: org/clojure/tools.logging/1.0.0/tools.logging-1.0.0.jar from
Downloading: org/clojure/tools.cli/1.0.194/tools.cli-1.0.194.jar from
Downloading: org/clojure/tools.analyzer.jvm/0.7.3/tools.analyzer.jvm-0.7.3.jar from
Downloading: org/clojure/tools.macro/0.1.1/tools.macro-0.1.1.jar from
Downloading: clj-logging-config/clj-logging-config/1.9.12/clj-logging-config-1.9.12.jar from
Downloading: org/flatland/useful/0.10.6/useful-0.10.6.jar from
Downloading: ring/ring-defaults/0.3.2/ring-defaults-0.3.2.jar from
Downloading: org/clojure/clojurescript/1.10.597/clojurescript-1.10.597.jar from
Downloading: funcool/cuerdas/2.2.1/cuerdas-2.2.1.jar from
Downloading: binaryage/devtools/1.0.0/devtools-1.0.0.jar from
Downloading: ring/ring-anti-forgery/1.3.0/ring-anti-forgery-1.3.0.jar from
Downloading: clj-sub-command/clj-sub-command/0.5.1/clj-sub-command-0.5.1.jar from
Downloading: com/rpl/specter/1.1.3/specter-1.1.3.jar from
Downloading: me/raynes/conch/0.8.0/conch-0.8.0.jar from
Downloading: log4j/log4j/1.2.16/log4j-1.2.16.jar from
Downloading: binaryage/dirac/1.5.8/dirac-1.5.8.jar from
Downloading: org/clojure/core.async/1.0.567/core.async-1.0.567.jar from
Exception in thread "main" clojure.lang.ExceptionInfo: Unable to locate Chromium executable
=> {:config {:verbosity 1, :command :launch, :profile "default", :log-level "INFO"}}
at dirac.main.actions.launch$locate_chromium_by_search.invokeStatic(launch.clj:36)
at dirac.main.actions.launch$locate_chromium_by_search.invoke(launch.clj:30)
at dirac.main.actions.launch$locate_chromium.invokeStatic(launch.clj:43)
at dirac.main.actions.launch$locate_chromium.invoke(launch.clj:40)
at dirac.main.actions.launch$launch_BANG_.invokeStatic(launch.clj:192)
at dirac.main.actions.launch$launch_BANG_.invoke(launch.clj:182)
at dirac.main$dispatch_BANG_.invokeStatic(main.clj:18)
at dirac.main$dispatch_BANG_.invoke(main.clj:15)
at dirac.main$_main.invokeStatic(main.clj:30)
at dirac.main$_main.doInvoke(main.clj:24)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
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)
I was unable to figure out what exactly tools deps is doing, I think the message about maven is wrong, it should be trying clojars as well. but doing another deploy using the same scripts worked, so version 1.5.9 is good
btw. I repeated the same thing, first deploy of 1.5.9 failed with “no checksums provided” and then I fixed the leiningen and deployed again with success, and the deployed file is correct
the strange thing is that 1.5.8 looks good on http://clojars.org via web interface
Clojars tries to make deploys atomic. Deploys go to a staging repo, then validation is performed on the deploy to try to confirm it is correct (that's where the no checksums provided for dirac-1.5.8.jar.asc
message comes from). If all the validation succeeds, the deploy is then moved in to the real repo. So you can redeploy the same version if it failed.
And 1.5.8 seems fine to me - it downloads for me w/o issue.
The reason tools.deps
is reporting that it can't find it in Maven Central is because it doesn't know where artifacts live, it just asks each repo from its list of repositories in order, and Maven Central is first. If it can't find it in one repo (meaning it got a 404), it will try the next repo in the list. If no repo has it, it will report that it could not find it in the first repo it tried I believe.
If you rm ~/.m2/repository/binaryage/dirac/1.5.8
and rerun your tools.deps invocation, does it then download it?
I don't know much about deps - is there a way to have it print the repos it is using?
so it works for you, so maybe it is just some cache issue, maybe between me and clojars
That's a good point - Fastly does cache 404s, so it's possible the edge node that is serving you has cached that 1.5.8 does not exist, but the one serving me did not. That means that 1.5.8 should work for you in < 24 hours, since that's the TTL
Re "If no repo has it, it will report that it could not find it in the first repo it tried I believe." this is correct. If there are multiple failures, tools.deps reports the first one (which repo that is is kind of arbitrary), but really that typically means it was not able to get from any repo.
this is hard to "fix" as there's no way to know which repo it was supposed to have been downloaded from. you could report all, but in some cases (multiple repos configured), you would see a flood of errors which would not actually give you any additional info.
hmm, the message could be general without mentioning a repo or print something like “tried central (…) and 2 others” this way it is quite misleading, because I spent quite some time fishing in my config files whether clojars is really configured as my secondary repo
I ended up hardcoding :mvn/repos
in my deps.edn just to be sure, but I couldn’t force their order to really confirm that clojars was actually tried
these messages are just coming out of maven and are only one of many errors that could be reported (differing only in message). doing what you just suggest means basically parsing and analyzing error message strings emitted from maven
if you use the mvn tool itself, I think it makes similar choices iirc