hcsshim currently depends on github.com/containerd/containerd. This dependency is only required for the containerd-shim binary, not for the library itself.
For library users, this means inheriting an unused, substantial dependency. Stripping down the dependency graph is good for download and compilation speed, as well as auditability. Additionally, as containerd prepares for its 2.x release and introduces the new containerd 1.8 API package, trying to use hcsshim along with the containerd 1.8 API in the same downstream project introduces some nasty package ambiguities.
How about moving the commands into their own Go submodules? That way, their specific dependencies won't affect the core library, reducing the dependency tree and making it easier for downstream consumers of hcsshim.
hcsshim currently depends on
github.com/containerd/containerd. This dependency is only required for the containerd-shim binary, not for the library itself.For library users, this means inheriting an unused, substantial dependency. Stripping down the dependency graph is good for download and compilation speed, as well as auditability. Additionally, as containerd prepares for its 2.x release and introduces the new containerd 1.8 API package, trying to use hcsshim along with the containerd 1.8 API in the same downstream project introduces some nasty package ambiguities.
How about moving the commands into their own Go submodules? That way, their specific dependencies won't affect the core library, reducing the dependency tree and making it easier for downstream consumers of hcsshim.