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/...
```
This is important to improve reliency of other automations/scripts that are using this script internally. Otherwise install script might stall forever in some cases.
The install script fails and thinks that alpine linux is in windows. This is because
`$OSTYPE` in alpine linux is linux-musl, not linux-gnu as this script assumes.
I tested these changes with this script:
```
set -euo pipefail
opsys=""
function check {
opsys=windows
if [[ "$OSTYPE" == linux* ]]; then
opsys=linux
elif [[ "$OSTYPE" == darwin* ]]; then
opsys=darwin
fi
}
OSTYPE="linux-gnu"
check
test "$opsys" == "linux" || echo $OSTYPE test failed
OSTYPE="linuxsomething"
check
test "$opsys" == "linux" || echo $OSTYPE test failed
OSTYPE="darwinsomething"
check
test "$opsys" == "darwin" || echo $OSTYPE test failed
OSTYPE="either"
check
test "$opsys" == "windows" || echo $OSTYPE test failed
```
ref: #2146
