Fork me on GitHub
#tools-deps
<
2020-08-09
>
borkdude20:08:43

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.

borkdude20:08:29

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?

vlaaad20:08:07

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.

dominicm20:08:34

I don't think maven does have that implicit thing, does it?

dominicm20:08:44

They're very big on groups

borkdude20:08:48

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.

borkdude20:08:42

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.

dominicm20:08:49

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)

borkdude20:08:01

Anyway, I hope that I turn off the warning for transitive deps, since I'm getting a ton of them:

[email protected] ~/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=>

seancorfield20:08:03

@borkdude You're only getting those for git deps -- not for all transitive deps.

seancorfield20:08:54

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.

borkdude20:08:57

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.

borkdude20:08:12

1 and 2 aren't shown in the output, I already fixed those.

alexmiller20:08:11

You are getting these any time clj reads any deps manifest

alexmiller20:08:15

So would for 4 as well

alexmiller20:08:06

I could tailor these more, but this is a step towards removing support entirely

alexmiller20:08:03

The thing I’m really trying to get rid of here is the need for canonicalization of libs when reading deps files

seancorfield20:08:47

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 🙂 )

borkdude20:08:59

Well, leaving it as it is now will probably force people to update their deps.edns quicker ;)

alexmiller20:08:33

Well that’s the idea :)

dominicm21:08:55

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.

borkdude21:08:44

I think that example just shows how .core doesn't contribute to avoiding conflicts while still having a multi-segmented name

seancorfield21:08:03

I think .core is a horrible default 😐

💯 3
seancorfield21:08:29

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 🙂

cfleming23:08:52

@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)]
to:
(let [{roots false, nonroots true} (group-by #(-> % val :dependents empty? not boolean) lib-map)]

cfleming23:08:39

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.

cfleming23:08:06

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.

seancorfield23:08:31

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!).

cfleming23:08:50

Well, it’s changed from appearing to not appearing at all.

seancorfield23:08:32

Ah, yes, that would definitely break my script. I hadn't actually tested basic output yet.

cfleming23:08:38

~/d/c/issues (master)> clj -Stree
~/d/c/issues (master)>

seancorfield23:08:36

Well... I guess I don't need to debug my script 🙂