The short & medium term future of library packaging in the tools.deps ecosystem

[slipset]

I moved the discussion in #22 to here, as it seems like a more suitable place

[slipset]

My current thoughts on this is the following:

1. Move off of depstar and rather use functionality in tools-build
2. Deprecate install and rather promote the functionality in tools-build
3. Make deps-deploy convenient to use from tools-build by providing building blocks which are usable for other tools-build, well, tools
4. Be available to help Cognitect (if needed) to add deploy functionality to tools-build

[seancorfield]

My build-clj library provides a wrapper for deploy: https://github.com/seancorfield/build-clj/blob/main/src/org/corfield/build.clj#L194-L216

This currently requires :lib and :version and has "sane" defaults for :target, :class-dir, and :jar-file -- mirroring tools.build naming -- with additional support for :artifact, :installer, and :pom-file from deps-deploy itself. The default for :pom-file is derived from :lib and the :class-dir (the latter has a default derived from :target, which itself has a default).

tools.build's install task requires :basis, :lib, :version, :class-dir, :jar-file. My wrapper has a "sane" default for :basis but that is a "gap" between deps-deploy's local install and the tools.build version (to pick up :mvn/local-repo).

It would make sense for my wrapper to switch to tools.build directly for local installs and to have the deploy task continue to use deps-deploy (and drop the :installer option and perhaps the :artifact option -- since :jar-file is the tools.build naming).

I'm going to open an issue on build-clj to add an install task using tools.build and to add at least a warning in the deploy task if :installer is passed in and is not :remote. seancorfield/build-clj#6