Move *.go files for subcommand out main package

[sctb512]

What is the problem you're trying to solve

I wish to import the nerdctl subcommand package to add some new features.

Describe the solution you'd like

Move *.go files for subcommand out of the main package so we can import it.

Additional context

In addition, are there any other ways to implement this?

[AkihiroSuda]

@sctb512

What function actually do you want to be exposed?

[AkihiroSuda]

Cross-posting #1639 (comment)

Sorry, I have to admit that I'm unable to review/carry this amount of PR 🙇‍♂️

Possible plan B might be incrementally separating out cobra-independent functions into pkg directory but I'm not sure we need to do so because codes under cmd/nerdctl are tightly coupled.

Yes, this should be done in a series of small PRs if we want to continue this. e.g.,

• PR 1: move cobra-independent functions into pkg/...
• PR 2: split other common functions into somewhere like cmd/nerdctl/cmdpkg/...
• PR 3: split the client cmdpkg
• PR 4: split nerdctl namespace
• PR 5: split nerdctl apparmor
• PR 6: split nerdctl builder
• PR 7: ...

The git diff has to be kept minimal for ease of reviewing and potential rebasing. It mustn't contain unnecessary changes such as exposing private functions. Some private functions could be exposed, but it has to be done in a separate PR.

Also, there shouldn't be the common package that is likely to result in being the home of random mutually irrelevant functions; the common package has to be split to multiple small cmdpkgs with clear purposes.

We also have to revisit whether we really have to split cmd/nerdctl in the first place ( #1631 (comment) ), as the functions in cmd/nerdctl aren't really designed to be imported from other projects. There might be some functions that can be safely imported from third parties, but they should be rather decoupled from the CLI and should be moved to pkg/... .

Then there might be no good reason to split cmd/nerdctl ? I expected that splitting cmd/nerdctl will increase the code readability as a side effect, but improper splitting will rather decrease the readability, so it has to be done seriously carefully.

@Zheaoli Thanks anyway for your hard work, and hope you will get well soon! 👍

[sctb512]

@sctb512

What function actually do you want to be exposed?

Thanks for your reply. I want to add features for nerdctl run subcommand. If we can split subcommand into a package, It will benefit developers.

There are two reasons:

1. The files in cmd/nerdctl are too many.

2. We cannot import them as packages because they all belong to the main.

[sctb512]

Moreover, I want to add a feature for nerdctl run to record accessed files when a container is running. If it is acceptable, We could consider adding it to the nerdctl source code and contributing it to the community.

[sctb512]

There is some information about it. containerd/nydus-snapshotter#228

[AkihiroSuda]

cc @ktock

[sctb512]

Also, there shouldn't be the common package that is likely to result in being the home of random mutually irrelevant functions; the common package has to be split to multiple small cmdpkgs with clear purposes.
We also have to revisit whether we really have to split cmd/nerdctl in the first place ( #1631 (comment) ), as the functions in cmd/nerdctl aren't really designed to be imported from other projects. There might be some functions that can be safely imported from third parties, but they should be rather decoupled from the CLI and should be moved to pkg/... .
Then there might be no good reason to split cmd/nerdctl ? I expected that splitting cmd/nerdctl will increase the code readability as a side effect, but improper splitting will rather decrease the readability, so it has to be done seriously carefully.

Yes, I couldn't agree more that we should consider it carefully. One reason for this is to add private features for nerdctl.