Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[WIP / RFC] separate command-line to a separate module #50

Closed
wants to merge 1 commit into from

Conversation

thaJeztah
Copy link
Member

(This is a very quick attempt at "what this will look like")

This repository provides both command-line utilities, and a module for external
consumers.

Currently, both are part of the same module; as a result, dependencies of both
the module and the command-line utilities are listed in the repositories go.mod.
This affects consumers of this project, because (due to go module's nature of
dependency (version) resolution), those consumers will inherit all dependencies,
or will be "forced" to use the same version of the CLI dependencies.

This is a very quick attempt at separating the CLI utilities from the "module",
by creating a separate go.mod (and module) for the CLI utilities.

I'm not fond of the name (github.com/containerd/imgcrypt/cmd) for that module
(possibly renaming to github.com/containerd/imgcrypt/cli would be slightly
clearer).

This change will add some additional work when tagging releases; a separate tag
should be created for the cli utilities (tagging as cmd/vX.Y.Z), and the
"github.com/containerd/imgcrypt" dependency in the go.mod inside the cmd directory
may need to be updated to reflect the latest version of the main module when tagging
new releases (as the replace rule is non-transitional); something like:

  1. update github.com/containerd/imgcrypt version in cmd/go.mod to "next release"
  2. tag both v<new release> and cmd/v<new version> in tandem.

CI / validation also needs to be updated to verify both go.mod and go.sum
files are correct / up-to-date. Possibly checks should be added to make sure the
main module is isolated from the cmd module (i.e., the "module" should not import
any path from the cmd directory: the reverse is of course OK (and expected)).

Finally; use of the 'vendor' directory may need to be discussed; it is common
to only use a vendor directory for projects that produce binaries, but omit the
vendor directory for "library" projects. In this case (if vendoring is still
desired), the vendor directory should be removed from the root of the repository,
and moved inside the cmd directory.

Signed-off-by: Sebastiaan van Stijn github@gone.nl

(This is a very quick attempt at "what this will look like")

This repository provides both command-line utilities, and a module for external
consumers.

Currently, both are part of the same module; as a result, dependencies of both
the module *and* the command-line utilities are listed in the repositories go.mod.
This affects consumers of this project, because (due to go module's nature of
dependency (version) resolution), those consumers will inherit all dependencies,
or will be "forced" to use the same version of the CLI dependencies.

This is a very quick attempt at separating the CLI utilities from the "module",
by creating a separate go.mod (and module) for the CLI utilities.

I'm not fond of the name (github.com/containerd/imgcrypt/cmd) for that module
(possibly renaming to github.com/containerd/imgcrypt/cli would be slightly
clearer).

This change _will_ add some additional work when tagging releases; a separate tag
should be created for the cli utilities (tagging as `cmd/vX.Y.Z`), and the
"github.com/containerd/imgcrypt" dependency in the go.mod inside the cmd directory
may need to be updated to reflect the latest version of the main module when tagging
new releases (as the replace rule is non-transitional); something like:

1. update `github.com/containerd/imgcrypt` version in cmd/go.mod to "next release"
2. tag both `v<new release>` and `cmd/v<new version>` in tandem.

CI / validation also needs to be updated to verify both `go.mod` and `go.sum`
files are correct / up-to-date. Possibly checks should be added to make sure the
main module is isolated from the cmd module (i.e., the "module" should not import
any path from the cmd directory: the reverse is of course OK (and expected)).

Finally; use of the 'vendor' directory may need to be discussed; it is common
to only use a vendor directory for projects that produce binaries, but omit the
vendor directory for "library" projects. In this case (if vendoring is still
desired), the vendor directory should be removed from the root of the repository,
and moved inside the `cmd` directory.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah
Copy link
Member Author

Somewhat related to containerd/btrfs#34 (comment) (similar situation)

@dims @stefanberger @estesp @mikebrow @AkihiroSuda wdyt? (mostly opening this for discussion / consideration: as mentioned, this would likely need some additional work)

@stefanberger
Copy link
Contributor

I am not the expert on this but it looks good to me...

@lumjjb
Copy link
Collaborator

lumjjb commented Jul 9, 2021

I like this idea, I do think that this doesn't necessarily introduce much overhead with having a separate release for cmd since we explicitly want the cli utility for testing and not for general consumption.

@kzys
Copy link
Member

kzys commented Mar 22, 2022

I love to see this!

@thaJeztah
Copy link
Member Author

ah, yes, keep forgetting about this one, and hadn't find the time yet to work on it (I'll try to find time, but if you (or someone else) wants to pick that up, please do!)

@AkihiroSuda
Copy link
Member

AkihiroSuda added a commit that referenced this pull request Apr 4, 2024
[Carry #50] separate command-line to a separate module
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants