Clojurians Log v2

I think they are technically SNAPSHOT builds

if I understand Maven version parsing correctly, they should be treated as 0.0.0-SNAPSHOT

but it doesn't see like that artifact/version exists in the repo (I do see a DEVELOP version)

Thanks Alex! > I think they are technically SNAPSHOT builds Oh, that would be good to know. Maven docs I read state that a -SNAPSHOT suffix should be used. But that was a https://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version, not a spec. Could be there is confusion with the various parseq libs... Clojars description page: https://clojars.org/com.gitlab.vise890/parseq/versions/SNAPSHOT Clojars repo: https://repo.clojars.org/com/gitlab/vise890/parseq/SNAPSHOT/ When I try to fetch:

$ clojure -Sdeps '{:deps {com.gitlab.vise890/parseq {:mvn/version "SNAPSHOT"}}}' 
Error building classpath. Could not find artifact com.gitlab.vise890:parseq:jar:SNAPSHOT in central ()

❯ clojure -Sdeps '{:deps {com.gitlab.vise890/parseq {:mvn/version "0.0.0-SNAPSHOT"}}}'
Error building classpath. Could not find artifact com.gitlab.vise890:parseq:jar:0.0.0-SNAPSHOT in central ()

that last link is typical I think of a snapshots (which is really a virtual version backed by timestamped versions), but I tested some stuff at lower levels in the api and afaict, the Maven apis can't see that, probably due to the version weirdness somehow

Thanks! My interpretation was that SNAPSHOT on its own does not signify a snapshot build, that clients see it that way, but clojars does not, hence a mismatch. But I'll dig around and learn more.

Maven stuff is vague enough (and has rewritten impls enough) that I find it hard to deduce what is "right", and easy to believe different pieces of code would interpret this as either a textual version (which is allowed) or as a snapshot version with numbers omitted

Oh poo (but thanks, good to know!).

Since neither lein nor clojure tools deps seem to resolve artifacts with a SNAPSHOT version, maybe I'll just have cljdoc skip these artifacts.

This is interesting. The sample project is stored as a snapshot (with timestamped versions) because whatever client deployed it decided it is a snapshot (the deploying client is responsible for creating the timestamped versions). But Clojars doesn't consider it a timestamp based on the version (the check in the code for snapshot is (.endsWith version "-SNAPSHOT")). But it doesn't matter what the Clojars code thinks it is when you are trying to pull it from the repo; the repo structure for the release is based on whatever the deploying client gave us.

Oh that clarifies tons @tcrawley, thanks! It is the deploying client that decides how the artifact is structured in the repo. So clojars is not doing any "classifying" as I earlier claimed/guessed.

So a deploying client can technically deploy an artifact that tools will not be able to retrieve.

Which seems to have unintentionally happened in this ambiguous edge case.

Ah, non SNAPSHOT case, a version that uses + instead of - • desc: https://clojars.org/com.mouryaravi/faraday/versions/1.11.1+protocol • repository: https://repo.clojars.org/com/mouryaravi/faraday/1.11.1%2Bprotocol/ This seems to be unresolvable with clojure cli:

$ clojure -Sdeps '{:deps {com.mouryaravi/faraday {:mvn/version "1.11.1+protocol"}}}'   
Error building classpath. Could not find artifact com.mouryaravi:faraday:jar:1.11.1+protocol in central ()

tdeps is just asking the repo for the version as a string - so either its in the maven apis or in the repo structure itself where things go astray. I notice that lib has 0 downloads, so clearly no one is getting to it