Trying to understand why you're packaging the prebuilt binary vs. building the code yourself. Can you elaborate on that?

As far as I can tell there is no hosted tarball archive for this binary, hence this binary install approach.

Do you mean that they don't host the source anywhere? https://github.com/kubernetes/kubernetes/tree/master/pkg/kubectl would probably work fine with a fetchFromGitHub subdirectory or the like. We also have a full k8s package from @offlinehacker and others that might also include kubectl.

@copumpkin I just wanted this tool, not the entire kubernetes install as I am simply administering a kubernetes cluster on google container engine.

This is my first nixpkgs PR. I thought seeing as there were a bunch of other basically pre-compiled tools in the nixpkgs set, that downloading this one (despite not being compressed) would also be fine. Happy to build the kubectl binary from the github-hosted source as well if that is the preferred means of building these kinds of derivations. But then, I'm not reallly au fait with the the intrinsic weirdness of golang builds.

@jamesthompson we don't have any explicit rule against binary packages but generally prefer builds from source wherever possible.

On the necessity of this vs. the full k8s package, I'm wondering if we could just split the outputs from the main k8s package so folks like you wouldn't need to get the full thing, but we wouldn't be incurring additional maintenance by having two packages with essentially the same tool (but with separate version numbers needing to be bumped regularly, probably getting out of sync, etc.).

@offlinehacker @NeQuissimus any opinion on splitting kubectl into a separate output on the main k8s derivation?

I also only need kubectl and currently I'm using

pkgs.kubernetes.override { components = [ "cmd/kubectl" ]; })

and it works without problems.

It's slightly annoying that I have to compile and it takes a long time and lots of memory (I had to add a swapfile just to be able to compile this). But I think it'd be better if we just add this line to all-packages.nix and get binary caches from Hydra without depending on a prebuilt binary.

Could we maybe use another output in the kubernetes derivation to expose kubectl? Then we wouldn't have to rebuild so much go code.

Ping :) I'd love to see kubectl as a separate output that I can pull in without the rest of k8s... Any takers? :D

Although... Maybe we should keep kubectl separate altogether because it will be much easier to update. It seems the full k8s is complex to update, kubectl is a fairly simple binary...

I can't decide which I like better :D

Is the protocol reasonably stable?

Reasonably, yes...
It is possible to use a newer cluster with our kubectl derivation.

I have something similar to @utdemir that I use because I like to keep the versions in-sync:

    ((pkgs.kubernetes.override { components = [ "cmd/kubectl" ]; }).overrideAttrs (oldAttrs: {
      version = "1.9.0";
      name = "kubectl-1.9.0";
      src = fetchFromGitHub {
        owner = "kubernetes";
        repo = "kubernetes";
        rev = "v1.9.0";
        sha256 = "03383j5n66r5qv3y03g3v9vmvmzhpj3fzparsz1s22x1zzr4qg5a";
      };
    }))

We could just throw that into top-level so that Hydra builds it, I suppose.

Somewhat related, on #33954 for upgrading kubernetes to 1.9.1 there are some problems with tests. Please help! Then it will be possible to produce another package specifically for kubectl :)

Oh, I hadn't seen this PR when I made #34126, but I did basically exactly what @NeQuissimus and @copumpkin said. 😅

I'm going to close this out - given #34126 solves the basic need of this PR.