Update docs, & fully use [email protected]

Author: danopia

README.md

@@ -13,33 +13,45 @@ Earlier releases would need some codegen changes to be compatible.
 
 ## Module Layout
 
+NOTE: This section refers to a hypothetical dynamic-codegen endpoint.
+The current way of using this library is importing modules from
+[/x/kubernetes_apis](https://deno.land/x/kubernetes_apis).
+The latest Kubernetes release is used to generate the published modules,
+so you may start noticing a lack of parity if you are using a quite old cluster.
+
+---
+
 Versioning is tricky with Kubernetes APIs because every cluster can have a different surface.
 
 When referring to Kubernetes API surfaces, an exhuastive module path might look like this:
 
-* `//[email protected]/[email protected]/core@v1/mod.ts`
-* `//[email protected]/[email protected]/apps@v1beta1/mod.ts`
-* `//[email protected]/[email protected]/networking.k8s.io@v1/mod.ts`
+* `https://k8s-apis.deno.dev/v1/[email protected]/core@v1/mod.ts`
+* `https://k8s-apis.deno.dev/v1/[email protected]/apps@v1beta1/mod.ts`
+* `https://k8s-apis.deno.dev/v1/[email protected]/networking.k8s.io@v1/mod.ts`
 
 There's also third-party projects that register CRDs, such as cert-manager.
-It's unfortunate that OpenAPI specs aren't published by these projects,
-so generation will depend on access to a live cluster,
-or extending the codegen to accept CRD YAML files as input in place of OpenAPI JSON.
+OpenAPI specs are almost never published by these projects,
+so generating APIs for them generally means feeding CRD YAML files into the codegen and guessing.
+This is an imperfect art but so far works well for `cert-manager` and `exernal-dns`.
+Alternatively, the CRDs could be installed onto a real control plane and then the APIed extracted.
 
 Several examples of addressing third party APIs might be:
 
-* `//[email protected]/[email protected]/acme.cert-manager.io@v1alpha2/mod.ts`
-* `//[email protected]/[email protected]/externaldns.k8s.io@v1alpha1/mod.ts`
-* `//[email protected]/[email protected]/velero.io@v1/mod.ts`
+* `https://k8s-apis.deno.dev/v1/[email protected]/acme.cert-manager.io@v1alpha2/mod.ts`
+* `https://k8s-apis.deno.dev/v1/[email protected]/externaldns.k8s.io@v1alpha1/mod.ts`
+* `https://k8s-apis.deno.dev/v1/[email protected]/velero.io@v1/mod.ts`
 
-There's not really any, like, directory of CRDs, so we'll need to make the list ourselves..
+The only sort of 'directory' of CRDs is likely [Operator Hub](https://operatorhub.io/)
+though it is also lacking CRDs that are not explicitly tied to an "Operator".
+Otherwise, there's not really any, like, directory of just CRDs,
+so we'll possibly need to make a further list ourselves..
 
 Finally, for generating code within a cluster, it's pretty likely that a cluster's apis
-will be generated as one unit and stored in S3 or similar, and the paths are more straightforward:
+will be generated as one unit and possibly stored in S3 or similar, and the paths are more straightforward:
 
 * `//k8s_api_surface/batch@v1/mod.ts`
 
 In any case, the actual API client that works with authentication/transport
 will be served authoratatively from a normal deno repo:
 
-* https://deno.land/x/[email protected].1/mod.ts
+* https://deno.land/x/[email protected].4/mod.ts

generation/deps.ts

@@ -1,4 +1,4 @@
 export * as path from "https://deno.land/[email protected]/path/mod.ts";
 export * as YAML from "https://deno.land/[email protected]/encoding/yaml.ts";
 
-export type { ApiKind, JSONValue } from "https://deno.land/x/[email protected].1/mod.ts";
+export type { ApiKind, JSONValue } from "https://deno.land/x/[email protected].4/mod.ts";

lib/client.ts

@@ -2,4 +2,4 @@
 // kubernetes_apis itself only depends on specific files,
 // so this is provided an optional utility (as opposed to deps.ts)
 
-export * from "https://deno.land/x/[email protected].1/mod.ts";
+export * from "https://deno.land/x/[email protected].4/mod.ts";