Nix flake enablement for gardenctl-v2

[vasu1124]

What this PR does / why we need it:

We want to enable gardenctl for the nix community.

# with Nix (macOS, Linux, and Windows)
nix run github:gardener/gardenctl-v2 -- version

# development version
nix profile install github:gardener/gardenctl-v2

gardenctl --help

[SuperSandro2000]

I've left the explanations for the other things in open-component-model/ocm#625 (review) since I didn't want to copy paste them here.

[Kumm-Kai]

Hi, great to see a flake for gardenctl ❤️

Would it be possible to also add an overlay to the flake?:

overlays.default = final: prev: {
  ${pname} = self.packages.${prev.system}.${pname};
};

This would allow users to declaratively install this flake using overrides (e.g., for nixpkgs), without needing to define this override function themselves.

As gardenctl heavily depends on gardenlogin it might be a good idea to add gardenlogin to the inputs of this flake and wrap the gardenlogin binary with gardenctl using wrapProgram in postFixup?
However, as I'm quite new to nix, I don't know if this is actually a good idea 😅

When trying out this flake I additionally encountered the following error on shell startup:
/dev/fd/16:22: permission denied: /Users/REDACTED/.nix-profile/share/zsh/site-functions/_gardenctl
This is triggered by including source <(gardenctl rc zsh) in my .zshrc. The sourced script tries to generate the completion script & write it to $GCTL_COMPLETION_FILE (/Users/REDACTED/.nix-profile/share/zsh/site-functions/_gardenctl)...

[vasu1124]

Would it be possible to also add an overlay to the flake?

Give me some time to check the pro & cons. I first need the maintainers to merge this PR (but they insist that the vendorhash has to be automated as well ...)

add gardenlogin to the inputs of this flake

Will check as well. I currently like that this dependency is not made implicit (meaning, the user has to explicitly flake download each tool).

When trying out this flake I additionally encountered the following error on shell startup:

If you setup nix properly, the installShellCompletion of the derivation automagically includes the source <(tool-of-choice completion $SHELL), and those dotfiles/directories are made read-only. I think you have to seek out how to run your environment side by side with nix, the issue is that you are trying to overwrite nix.

[petersutter]

I first need the maintainers to merge this PR (but they insist that the vendorhash has to be automated as well ...)

Out of good reason. Take https://github.com/open-component-model/ocm as an example. The PR Make ocm flake.nix ready #625 was merged, and the go.mod dependencies were updated several times afterwards. However, the vendorHash was not updated at all, which was foreseeable.

[Kumm-Kai]

I 100% agree that the vendorHash should be updated automatically (at the very least CI should check if the flake can still build)... Otherwise, it's pretty much useless 🙃

@vasu1124

If you setup nix properly, the installShellCompletion of the derivation automagically includes the source <(tool-of-choice completion $SHELL), and those dotfiles/directories are made read-only. I think you have to seek out how to run your environment side by side with nix, the issue is that you are trying to overwrite nix.

I'm aware that most tools (installed with nix) are "installing" the completion scripts into a location I can use by adding it to $fpath (which I already do). However, the source <(gardenctl rc zsh) call in my .zshrc (documented here) is additionally used to create aliases and "start" the gardenctl environment.

I could specify everything on my own, instead of using source <(gardenctl rc zsh), but IMO the script ideally shouldn't create & save the completion scripts on every shell startup / call of the script.