|
| 1 | +/* |
| 2 | +Copyright 2018 The Kubernetes Authors. |
| 3 | +
|
| 4 | +Licensed under the Apache License, Version 2.0 (the "License"); |
| 5 | +you may not use this file except in compliance with the License. |
| 6 | +You may obtain a copy of the License at |
| 7 | +
|
| 8 | + http://www.apache.org/licenses/LICENSE-2.0 |
| 9 | +
|
| 10 | +Unless required by applicable law or agreed to in writing, software |
| 11 | +distributed under the License is distributed on an "AS IS" BASIS, |
| 12 | +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 13 | +See the License for the specific language governing permissions and |
| 14 | +limitations under the License. |
| 15 | +*/ |
| 16 | + |
| 17 | +// It's possible that kustomize's features will be vendored into |
| 18 | +// the kubernetes/kubernetes repo and made available to kubectl |
| 19 | +// commands, while at the same time the kustomize program will |
| 20 | +// continue to exist as an independent CLI. Vendoring snapshots |
| 21 | +// would be taken just before a kubectl release. |
| 22 | +// |
| 23 | +// This creates a problem in that freestanding-kustomize depends on |
| 24 | +// (for example): |
| 25 | +// |
| 26 | +// https://github.com/kubernetes/apimachinery/ |
| 27 | +// tree/master/pkg/util/yaml |
| 28 | +// |
| 29 | +// It vendors that package into |
| 30 | +// sigs.k8s.io/kustomize/vendor/k8s.io/apimachinery/ |
| 31 | +// |
| 32 | +// Whereas kubectl-kustomize would have to depend on the "staging" |
| 33 | +// version of this code, located at |
| 34 | +// |
| 35 | +// https://github.com/kubernetes/kubernetes/ |
| 36 | +// blob/master/staging/src/k8s.io/apimachinery/pkg/util/yaml |
| 37 | +// |
| 38 | +// which is "vendored" via symlinks: |
| 39 | +// k8s.io/kubernetes/vendor/k8s.io/apimachinery |
| 40 | +// is a symlink to |
| 41 | +// ../../staging/src/k8s.io/apimachinery |
| 42 | +// |
| 43 | +// The staging version is the canonical, under-development |
| 44 | +// version of the code that kubectl depends on, whereas the packages |
| 45 | +// at kubernetes/apimachinery are periodic snapshots of staging made |
| 46 | +// for outside tools to depend on. |
| 47 | +// |
| 48 | +// apimachinery isn't the only package that poses this problem, just |
| 49 | +// using it as a specific example. |
| 50 | +// |
| 51 | +// The kubectl binary cannot vendor in kustomize code that in |
| 52 | +// turn vendors in the non-staging packages. |
| 53 | +// |
| 54 | +// One way to fix some of this would be to copy code - a hard fork. |
| 55 | +// This has all the problems associated with a hard forking. |
| 56 | +// |
| 57 | +// Another way would be to break the kustomize repo into three: |
| 58 | +// |
| 59 | +// (1) kustomize - repo with the main() function, |
| 60 | +// vendoring (2) and (3). |
| 61 | +// |
| 62 | +// (2) kustomize-libs - packages used by (1) with no |
| 63 | +// apimachinery dependence. |
| 64 | +// |
| 65 | +// (3) kustomize-k8sdeps - A thin code layer that depends |
| 66 | +// on (vendors) apimachinery to provide thin implementations |
| 67 | +// to interfaces used in (2). |
| 68 | +// |
| 69 | +// The kubectl repo would then vendor from (2) only, and have |
| 70 | +// a local implementation of (3). With that in mind, it's clear |
| 71 | +// that (3) doesn't have to be a repo; the kustomize version of |
| 72 | +// the thin layer can live directly in (1). |
| 73 | +// |
| 74 | +// This package is the code in (3), meant for kustomize. |
| 75 | + |
| 76 | +package k8sdeps |
0 commit comments