mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-06-29 17:41:13 +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/... ```
30 lines
601 B
Go
30 lines
601 B
Go
// Copyright 2019 The Kubernetes Authors.
|
|
// SPDX-License-Identifier: Apache-2.0
|
|
|
|
package build
|
|
|
|
import (
|
|
"github.com/spf13/pflag"
|
|
)
|
|
|
|
const (
|
|
flagEnablePluginsName = "enable_alpha_plugins"
|
|
flagEnablePluginsHelp = `enable plugins, an alpha feature.
|
|
See https://github.com/kubernetes-sigs/kustomize/blob/master/docs/plugins/README.md
|
|
`
|
|
)
|
|
|
|
var (
|
|
flagPluginsEnabledValue = false
|
|
)
|
|
|
|
func addFlagEnablePlugins(set *pflag.FlagSet) {
|
|
set.BoolVar(
|
|
&flagPluginsEnabledValue, flagEnablePluginsName,
|
|
false, flagEnablePluginsHelp)
|
|
}
|
|
|
|
func isFlagEnablePluginsSet() bool {
|
|
return flagPluginsEnabledValue
|
|
}
|