mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-05-17 18:25:26 +00:00
b9f05dd357
The PR exposes some of the top level kustomize commands (especially `build`) for reuse in other command line tools (expecially `kubectl`, see #1500). This PR represents option 3 from the following list of ways this exposure could be arranged. 1. Expose the commands in the `api` module. ``` REPO/api/go.mod REPO/api/builtins REPO/api/commands <- new REPO/api/... ``` Disadvantage: This would make `api` module depend on cobra. That's bad for clients that want to depend on the api, but want to write their own commands at their own version of cobra. The `api` module shouldn't depend on UX libraries like cobra. 2. Expose the commands in their own `commands` module. They'd appear alongside `api`, e.g. ` ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/commands/go.mod REPO/commands/build REPO/commands/edit REPO/commands/... ``` Advantage: The commands would be consumed by the kustomize binary and the kubectl binary in the same way. Disadvantage: The kustomize binary module and the commands module could evolve separately with their own version numbers, creating confusion. 3. Expose the commands in the existing `kustomize` module ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/main.go REPO/kustomize/commands/build REPO/kustomize/commands/edit REPO/kustomize/commands/... ``` Outside users, e.g. kubectl, could then ``` import sigs.k8s.io/kustomize/kustomize/v3/commands/build ``` and hopefully still get the `main` package as they do now via: ``` go get sigs.k8s.io/kustomize/kustomize/v3 ``` Advantage: 1) The kustomize binary ships at the same version as the commands - which makes sense as the binary's _version_ refers to how the CLI operates (command names, flags, etc.). This makes it easy to related the version of a kustomize binary with the version of commands running in some other CLI binary. 2) The path to the kustomize binary doesn't change. Disadvantage: It's an atypical Go module arrangement. Usually `main` packages live as leaves under a directory called `cmd` inside a module, rather than at the _top_ of the module. This might cause some problems. If so, we can go with option 4. 4. Same as 3, but move `main.go` (the `main` package) down one step. ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/cmd/main.go REPO/kustomize/commands/build REPO/kustomize/commands/edit REPO/kustomize/commands/... ```
7 lines
166 B
Bash
Executable File
7 lines
166 B
Bash
Executable File
for f in $(find $1 -name '*.go'); do
|
|
echo $f
|
|
# go get golang.org/x/tools/cmd/goimports
|
|
# {or} go run go.coder.com/go-tools/cmd/goimports
|
|
goimports -w $f
|
|
done
|