Clojurians Log v2

Maven dep expansion uses only the pom to find transitive deps. You are correct that the Maven ecosystem does not understand git deps - those are better used during development or as tools, not libs

You can use git deps as part of an application -- we do that at work, for imagez since we need an unreleased bug fix -- but you can't have a library depend on git deps, unless that library itself is also intended to only be available via git deps. Neither Clojars nor Maven can support git deps (due to pom.xml).

I think that's fine if the user controls the lib, but there's a chance the vendor hasn't published it to Clojars at all even if the library could be considered "production ready". In those cases, are we recommended to try and vend the library ourselves if the maintainers can't/won't do it (e.g. unresponsive)?

It's bad form to publish someone else's library if they don't consider it ready for production.

You can ask the maintainer about depending on the library. They may find the idea of someone else using it sufficient to decide to publish a version themselves.

Is there a specific library for which you are asking, or is this just theoretical?

Mostly theoretical, though https://github.com/mentat-collective/emmy is somewhat in that camp but only because their Clojars release is ~1 year old and they recommend using git libs instead. This one's not a big problem though since I can just ping in #emmy and the library's not 1.x yet (so technically not production ready). I'm not sure I'd be able to say the same about various other seemingly abandoned libraries though.

Abandoned like... which libraries specifically?

If a library is widely useful and the maintainer has moved on, clj-commons is one path to releases and maintenance.

That I don't have any specific examples of and am just conjecturing about.

Emmy is really aimed at projects with interactive use, i.e., "application" contexts where git deps are fine.

For quite a while, tools.build was git deps only but folks asked to depend on it as a library and it started to get Maven releases. You can always ask when a specific case comes up.

Mmm it's a general computer algebra system, I wouldn't exactly say it's relegated to interactive use. Its expression symplifier makes it highly performant in a way that makes it suitable for use in non-interactive contexts as well (e.g. higher level math libs).

I took that from its README which says it's best used in an interactive REPL-based context 🙂

I guess my concern is that the Git vending mechanism poisons the Maven vending mechanism so they get complected. If a library author makes their library open source, they're fine with consumption regardless of the vending mechanism (Git or Maven lib) or use case (development or production) since licenses usually come with a "use at your own risk" clause. The (supposed) intention of tools.deps/`deps.edn` is that Git vending is mostly used for development and Maven vending is used for production. The reality is that users may use the Git procurer for production (e.g. has a bunch of private Git repos and doesn't want to deal with a private Maven registry). It kind of comes down to intentions v. actual use. To me it doesn't feel like the vending mechanism should matter. Many other dependency management systems are fine with mixing Git and artifact registry approaches (e.g. npm, Python).

From a library vendor's perspective, vending Git libs is also just better from a technical perspective because you don't run into this elided deps problem.

Though that causes other problems for corporate use cases (e.g. mandate you use a private registry mirror that does security scanning).

Like I say, if there are specific libraries that are git-only and that causes you a problem, ask the maintainer to make a Clojars release.

If you are a library maintainer yourself, it's up to you to decide how you want to support your users. For example, deps-new relies on actual source files on disk because it uses tools.build functions for copying / substituting files. So you can't publish a template to Clojars: it just won't work. So deps-new also doesn't have a Clojars release. My log4j2 conflict handler library is designed specifically for use with build.clj and tools.build so it's currently git-only, but in the same way tools.build now has Maven releases, if someone wanted to use my conflict handler "as part of a library", they could ask me to start making Clojars releases and I'd consider it.

Clojure, as a source-first language, does not need and should not only work from Maven deps. We certainly want to leverage that part of the ecosystem, but not be beholden to it. When deploying things to Maven for use by others, there are choices to be made for dependencies not available in Maven. There might be other source-only targets that we add support for in the future. One possible future answer is to write a Maven pom plugin that would resolve dependencies from Git. Doing that work is ... unexciting? but would be useful for that end of things. I'm not sure that would be easily usable from Leiningen though, where creating support for deps.edn libs more directly might be better.

Git Deps are annoying that way 100% agree, and can be seen as a negative to Clojure. But they are also pretty convenient when you can leverage them. So that can be seen as a positive. I have seen people publish other people's git-libs to Maven for their own use. I disagree with others on it being bad form. To me, it's like forking and publishing your fork, except you made no changes. The openJDK for example is vendored by many vendors. I feel it's in the spirit of open source. That said, asking first is definitely a good gesture. Another issue with git-deps, is for enterprise use, as it doe snot work with Artifactory and other Maven based internal caches and such.

I am very interested in making it work for Artifactory etc

Maybe it can be done with Artifactory using: https://jfrog.com/integration/git-repository/ We use an internal only cache, not a 3rd party solution. So it isn't as featured. And since we're a Java shop, they just put the work on to support Maven.

Internal cache of git or Maven?

Maven only. If the company was all-in on Clojure, I'm sure it be solved, but it's mostly Java. So they only proxy maven-central and clojars.

I assume the Git procurer downloads the entire repo to ~/.gitlibs since it's just shelling out to git (so it's not being granular with only downloading deps.edn before downloading the rest of the repo). The Maven curator is basically using the pom.xml (which Maven registries let you download separate from the JAR) as an optimization, so maybe downloading the JAR and looking for the deps.edn and pom.xml within it instead might bring it inline with the Git procurer. Decompression can be done with jar which comes with Java (required anyways). That seems like something that would work with arbitrary source vending mechanisms since all that matters is a deps.edn in the artifact root.

Granted that may be a lot more data being moved around now which is...not so nice.

The procurer stuff is an open set of multimethods but there is not currently a way to install extensions in the CLI, but that’s an eventual thing to do