# Pseudo k8s

[kubernetes/api]: https://github.com/kubernetes/api
[kubernetes/apimachinery]: https://github.com/kubernetes/apimachinery
[kubernetes/client-go]: https://github.com/kubernetes/client-go
[init-pseudo-module.sh]: init-pseudo-module.sh

The module defined below in `pseudo/k8s` contains code generated by the
[init-pseudo-module.sh] script.

The module contains clones (see the [script][init-pseudo-module.sh] for the specific clone tag) of code from the following repositories:

- [kubernetes/api]
- [kubernetes/apimachinery]
- [kubernetes/client-go]

These repositories are in turn snapshots of code being developed
in [kubernetes staging](https://github.com/kubernetes/kubernetes/tree/master/staging).

## Why?

[`cli-runtime`]: https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/cli-runtime
[`apimachinery`]: https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/apimachinery

In what follows, let the word `apimachinery` generally represent one of more of the modules [kubernetes/api], [kubernetes/apimachinery], [kubernetes/client-go].

 - kubectl depends on `apimachinery` in the k/k repo via a `go.mod` replacement.

 - kubectl must depend the on kustomize API module.

 - `apimachinery` doesn’t yet do releases distinguished by major version number.  I.e., one cannot write a `go.mod` file containing the lines
   > ```
   > require k8s.io/apimachinery    v1.1.4
   > require k8s.io/apimachinery/v2 v2.1.0
   > require k8s.io/apimachinery/v3 v3.2.1
   > ```
   The only option at this time are pseudo-versions of the form `v0.0.0-20181127025237-2b1284ed4c93` and everything in the k/k repo must depend on exactly one pseudo version, which is typically a v.0.0.0 with a replace directive specifying an in-repo relative path.

 - kustomize depends on `apimachinery`.

This creates a problem, since kubectl and kustomize have no means to declare a dependence on different versions of `apimachinery`, and no means to sync on the same version since kubectl and kustomize live in different repositories.

A solution to this is a _manual vendor_: either the kustomize API module source code must be manually snapshotted into the k/k repo at some invented path that could never be confused with a normal module import path, or the `apimachinery` module (and friends) must be snapshotted into the kustomize repo using the same notion of import path replacement.

This module is the result of taking the latter option.  kustomize can depend on this snapshot of `apimachinery`, and both can be vendored into the k/k repo safely.


## Caveats

This pseudo k8s module may be removed at anytime in the future without warning and no
support will be given for these modules.
It's best to try to encourage semver development in `apimachinery` directly.

## How was this module made?

These libraries were forked by running `git clone` to clone the repos.

### Automated Creation Steps

1. Remove the current existing pseudo modules
  - `$ rm -rf pseudo/k8s`
2. Run the [init-pseudo-module.sh](init-pseudo-module.sh) script to clone and configure pseudo deps
  - From the root directory -- `$ pseudo/init-pseudo-module.sh`