Clojurians Log v2
tools-deps
I get a ton of "DEPRECATED libs must be qualified" warnings not from my own deps.edn, but for transitive deps. Can I somehow turn that off? It's not something I can fix in my own codebase.
Also one thought: would it make sense to only deprecate it for git deps and not for mvn deps, since mvn already has the foo = foo/foo implicit convention and there's not much tools.deps is going to change about that?
This is not about foo=foo/foo convention, this about a way of thinking about dependencies. Shorthands incentivize names squatting, full group/artifact names make you think who you depend on. I'd rather depend on borkdude/clj-kondo than on just clj-kondo. I'd rather released vlaaad/cljfx than just cljfx... I think it makes sense to state group/artifact for every procurer.
I don't think maven does have that implicit thing, does it?
They're very big on groups
If you push a library foobar with lein to clojars, it's really foobar/foobar, so the group is foobar and the library is also called foobar. That's what I mean with a mvn library. The mechanism for pushing/retrieving is based on mvn. I know avoiding conflicts is important, but this convention has been there since ages in leiningen. Is this a lein convention or a mvn convention, I'm not sure. I haven't used pom.xml directly that much.
So is this a design mistake of lein that deps now tries to solve? I totally understand the need for git deps to have a unique and predictable identifier.
I suspect it's a lein and clojars thing. Maven central won't let you create an artifact like that, only clojars does (to controversy)
Anyway, I hope that I turn off the warning for transitive deps, since I'm getting a ton of them:
borkdude@MBP2019 ~/Dropbox/dev/clojure/babashka (master) $ clojure -Sforce -A:lib-tests
DEPRECATED: Libs must be qualified, change expound => expound/expound (/Users/borkdude/.gitlibs/libs/lambdaisland/regal/b059fdb06d5586a9a04c27e7b011c467ad8546db/deps.edn)
DEPRECATED: Libs must be qualified, change instaparse => instaparse/instaparse (/Users/borkdude/.gitlibs/libs/lambdaisland/regal/b059fdb06d5586a9a04c27e7b011c467ad8546db/deps.edn)
DEPRECATED: Libs must be qualified, change medley => medley/medley (/Users/borkdude/.gitlibs/libs/henryw374/cljc.java-time/e3d184b78e933322b3fcaa6ca66cbb8f42a6b35c/deps.edn)
DEPRECATED: Libs must be qualified, change camel-snake-kebab => camel-snake-kebab/camel-snake-kebab (/Users/borkdude/.gitlibs/libs/henryw374/cljc.java-time/e3d184b78e933322b3fcaa6ca66cbb8f42a6b35c/deps.edn)
DEPRECATED: Libs must be qualified, change cljs.java-time => cljs.java-time/cljs.java-time (/Users/borkdude/.gitlibs/libs/henryw374/cljc.java-time/e3d184b78e933322b3fcaa6ca66cbb8f42a6b35c/deps.edn)
DEPRECATED: Libs must be qualified, change expound => expound/expound (/Users/borkdude/.gitlibs/libs/lambdaisland/regal/b059fdb06d5586a9a04c27e7b011c467ad8546db/deps.edn)
DEPRECATED: Libs must be qualified, change instaparse => instaparse/instaparse (/Users/borkdude/.gitlibs/libs/lambdaisland/regal/b059fdb06d5586a9a04c27e7b011c467ad8546db/deps.edn)
DEPRECATED: Libs must be qualified, change medley => medley/medley (/Users/borkdude/.gitlibs/libs/henryw374/cljc.java-time/e3d184b78e933322b3fcaa6ca66cbb8f42a6b35c/deps.edn)
DEPRECATED: Libs must be qualified, change camel-snake-kebab => camel-snake-kebab/camel-snake-kebab (/Users/borkdude/.gitlibs/libs/henryw374/cljc.java-time/e3d184b78e933322b3fcaa6ca66cbb8f42a6b35c/deps.edn)
DEPRECATED: Libs must be qualified, change cljs.java-time => cljs.java-time/cljs.java-time (/Users/borkdude/.gitlibs/libs/henryw374/cljc.java-time/e3d184b78e933322b3fcaa6ca66cbb8f42a6b35c/deps.edn)
Clojure 1.10.2-alpha1
user=>
@borkdude You're only getting those for git deps -- not for all transitive deps.
If you were depending on released versions, you wouldn't get those warnings. I've only had to update my current project deps to get rid of warnings -- but I don't generally depend on git deps.
I'm getting warnings for 1) my own git deps, 2) my own mvn deps, 3) mvn deps of transitive git deps. I'm not sure if a git dep depending on another git dep would also yield a warning, but I suspect this situation isn't that prevalent yet (let's call this 4). I understand the need for 1. 2 is disputable, but from a "let's fix what lein did wrong" perspective, I can live with it. 3 and 4 I wouldn't find acceptable.
1 and 2 aren't shown in the output, I already fixed those.
You are getting these any time clj reads any deps manifest
So would for 4 as well
I could tailor these more, but this is a step towards removing support entirely
1The thing I’m really trying to get rid of here is the need for canonicalization of libs when reading deps files
I have run across a handful of "single" named Java libs (`wsdl4j` plus a few others), but it's pretty rare in non-Clojure world. I agree that we've been very sloppy about that practice in the past (and I'm guilty a few times -- but I'm working to fix that 🙂 )
Well, leaving it as it is now will probably force people to update their deps.edns quicker ;)
Well that’s the idea :)
I'm glad there's more of a push on this. I've seen a few conflicts in libraries (I've seen at least two libraries using roll.core). I've gotten friction in the past because it's "verbose", so it's nice this will become non optional.
I think that example just shows how .core doesn't contribute to avoiding conflicts while still having a multi-segmented name
I think .core is a horrible default 😐
That's why clj-new doesn't do that. You must provide either a group-id/artifact-id project name (and the README talks about using reverse domain names or other identity-based groups) or you can provide a multi-segment namespace name. But I may downplay that option a bit more, now that t.d.a. is "encouraging" proper group/artifact lib names 🙂
@alexmiller -Stree seems to be broken since 1.10.1.624. It’s because previously root deps used to return nil in their :dependents set, and now they return an empty collection. This broke Cursive, I’ve fixed it there by inlining make-tree and changing:
(let [{roots false, nonroots true} (group-by #(-> % val :dependents boolean) lib-map)](let [{roots false, nonroots true} (group-by #(-> % val :dependents empty? not boolean) lib-map)]I’m not sure what the cause of that change is, I couldn’t see anything immediately suspicious in the changelog but I only had a fairly cursory look.
On a related note, is the :dependents/`:children` info returned from resolve-deps considered to be part of the API and thus something I can rely on? It’s not mentioned in the docstring.
The output of -Stree has certainly changed -- I just updated from .619 to .641 and my outdated deps script broke (so that'll be a bit of fun for me to debug and fix tomorrow morning when I get to work!).
Well, it’s changed from appearing to not appearing at all.
Ah, yes, that would definitely break my script. I hadn't actually tested basic output yet.
~/d/c/issues (master)> clj -Stree
~/d/c/issues (master)>Oops.
Well... I guess I don't need to debug my script 🙂