DEPRECATED: Libs must be qualified, change cljfmt => cljfmt/cljfmt (~/.clojure/deps.edn)

298 views
Skip to first unread message

D. Ben Knoble

unread,
Aug 6, 2020, 1:19:31 PM8/6/20
to Clojure
I've started seeing a lot of messages like this, I think after I updated clojure, but I can't find any documentation or points in the changelog about the change, why I'm getting this message, or what the correct fix is. I know it provides a change I can make, but is it the right one?

Some examples deps.edn that come up in this message:

~/.clojure/deps.edn

{:aliases
 {:runner
  {:extra-paths ["test"]
   :extra-deps {com.cognitect/test-runner
                {:git/url "https://github.com/cognitect-labs/test-runner.git"
                 :sha "209b64504cb3bd3b99ecfec7937b358a879f55c1"}}
   :main-opts ["-m" "cognitect.test-runner"]}

  :fmt
  {:extra-deps {cljfmt {:mvn/version "0.6.4"}}
   :main-opts ["-m" "cljfmt.main"]}

  :srepl
  {:jvm-opts ["-Dclojure.server.repl={:port,5555,:accept,clojure.core.server/repl}"]}

  :prepl
  {:jvm-opts ["-Dclojure.server.repl={:port,5555,:accept,clojure.core.server/io-prepl}"]}

  :rebel {:extra-deps {com.bhauman/rebel-readline {:mvn/version "RELEASE"}}
          :main-opts ["-e" "(use,'clojure.repl)"
                      "-m" "rebel-readline.main"]}

  :nrepl {:extra-deps {nrepl {:mvn/version "RELEASE"}}
          :main-opts ["-m" "nrepl.cmdline"]}

  :cider
  {:extra-deps {cider/cider-nrepl {:mvn/version "RELEASE"}}
   :main-opts ["-m" "nrepl.cmdline"
               "--middleware" "[cider.nrepl/cider-middleware]"]}

  :ciders
  {:extra-deps {org.clojure/clojurescript {:mvn/version "RELEASE"}
                cider/cider-nrepl {:mvn/version "RELEASE"}
                cider/piggieback {:mvn/version "RELEASE"}}
   :main-opts ["-m" "nrepl.cmdline"
               "--middleware" "[cider.nrepl/cider-middleware,cider.piggieback/wrap-cljs-repl]"]}}}


Project specific deps.edn:

{:deps
 {hiccup {:mvn/version "1.0.5"}
  ring {:mvn/version "1.8.0"}
  compojure {:mvn/version "1.6.1"}}

 :aliases
 {:spec
  {:extra-paths ["classes" "spec"]
   :extra-deps {speclj
                {:git/url "https://github.com/kyptin/speclj"
                 :sha "a843b64cc5a015b8484627eff6e84bbac2712692"}}
   :main-opts ["-m" "speclj.cli"]}

  :runner
  {:extra-paths ["test"]
   :extra-deps {com.cognitect/test-runner
                {:git/url "https://github.com/cognitect-labs/test-runner.git"
                 :sha "209b64504cb3bd3b99ecfec7937b358a879f55c1"}}
   :main-opts ["-m" "cognitect.test-runner"]}

  :fmt
  {:extra-deps {cljfmt {:mvn/version "0.6.4"}}
   :main-opts ["-m" "cljfmt.main"]}

  :explore-test
  {:extra-deps {clj-http {:mvn/version "3.10.0"}
                org.clojure/core.async {:mvn/version "1.1.587"}
                org.clojure/data.json {:mvn/version "1.0.0"}
                enlive {:mvn/version "1.1.6"}}
   :main-opts ["-m" "jst-explore-test-a6"]}}}


Perhaps the biggest question is—some of the deps are already qualified (com.cognitect/test-runner); doesn't that mean cljfmt/cljfmt may not be the right qualified form?

Additionally, I would love to know
- where this is documented
- what changed, and why

Alex Miller

unread,
Aug 6, 2020, 1:24:08 PM8/6/20
to Clojure
Hi, couple things here...

First, for information on this change you can see the section at the very end of this blog: https://insideclojure.org/2020/07/28/clj-exec/ - probably best to read that and then I can answer any follow-ups as I tried to explain there.

Second, this is only in a preview release of clj and has not been promoted to the stable release yet (you can find both at the official Clojure Homebrew tap (https://github.com/clojure/homebrew-tools). The core homebrew tap is not being updated by the Clojure team anymore and it seems someone has updated it past the newest stable release of `clj` so using the core tap may be giving you preview releases. So, use the official tap!

Alex

D. Ben Knoble

unread,
Aug 6, 2020, 5:58:32 PM8/6/20
to clo...@googlegroups.com
Thanks, super helpful. I'll follow-up if I have any questions.
D. Ben Knoble

Matching Socks

unread,
Aug 7, 2020, 7:44:48 AM8/7/20
to Clojure
Rich Hickey has pushed using solid domain names before, and I'm super glad to see more progress on that front.  But it's unfortunate if the tools castigate the victim, not the perpetrator.  Wouldn't Clojars be a better point for enforcement?  Has the question been raised with Clojars?  

Alex's advice reminds me of a pioneering ClojureScript React-wrapping library whose groupId is a domain that belongs to someone else.  The funny thing is that this is the library's *second* squatting.  The first one lasted only briefly; folks pointed out the domain was already used for an unflattering website.  So then the maintainers picked a domain that no one had registered at the time.  Risky!

Sean Corfield

unread,
Aug 7, 2020, 12:35:25 PM8/7/20
to Clojure Mailing List
The warning appears about your own use of unqualified lib names in your project's dependencies: so it really is "castigating the perpetrator", by making you use groupId/artifactId format names for dependencies, instead of the (lazy/convenient) shorthand of artifactId for libs that have a groupId that matches the artifactId.

At work that meant changing all our dependencies for: Ring (and several Ring-related libs), Selmer, Compojure, clj-http, http-kit, Hiccup, HoneySQL, Instaparse, joda-time (a Java library that does it badly!), wsdl4j (another naughty Java library!), Cheshire, clj-time, camel-snake-kebab, date-clj, bidi, clojure.java-time -- which is already a horrendous violator of both artifact naming _and_ namespace naming!).

On Fri, Aug 7, 2020 at 4:45 AM Matching Socks <phill...@gmail.com> wrote:
Rich Hickey has pushed using solid domain names before, and I'm super glad to see more progress on that front.  But it's unfortunate if the tools castigate the victim, not the perpetrator.  Wouldn't Clojars be a better point for enforcement?  Has the question been raised with Clojars?  

Alex's advice reminds me of a pioneering ClojureScript React-wrapping library whose groupId is a domain that belongs to someone else.  The funny thing is that this is the library's *second* squatting.  The first one lasted only briefly; folks pointed out the domain was already used for an unflattering website.  So then the maintainers picked a domain that no one had registered at the time.  Risky!

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/88400d9e-9c68-4098-9321-7cfb89e92be8o%40googlegroups.com.


--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- https://corfield.org/
World Singles Networks, LLC. -- https://worldsinglesnetworks.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Reply all
Reply to author
Forward
0 new messages