kustomize

mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-05-17 18:25:26 +00:00

Files

monopole b9f05dd357 Expose some top level kustomize commands.

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/...
```

2021-02-04 08:35:01 -08:00

krmFunctionBenchmark

Update readme.md

2020-07-13 12:24:34 -07:00

buildExternalGoPlugins.sh

Plugin loader improvements.

2020-04-18 18:29:10 -07:00

doGoMod.sh

Move hacks to hack (match k8s pattern).

2019-10-27 05:05:23 -07:00

generateBuiltinKrmFunctions.sh

fix script name