Add nix flake and direnv

[secobarbital]

What was changed

Added a nix flake with:

1. A devShell with all the tools in the correct versions for development
2. A nix derivation for the cli that is exposed as a package

Why?

1. Easily have everything set up to dev on the project, regardless of Go setup for other projects.
2. Consume the package in other nix flakes, e.g. temporal-server

Checklist

3. How was this tested:
   Follow the instructions in the README:

4. Make sure Nix is installed (https://docs.determinate.systems/getting-started/individuals/)

5. nix build will build the executable in result/bin/temporal

6. nix develop will activate a dev shell with go 1.24.4 and related tools

7. direnv allow will automatically activate the dev shell when entering the directory (install it with nix profile add nixpkgs#direnv)

8. Any docs updates needed?
   Only if the team decides to make the nix development environment a supported one.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cretz]

Thanks! We will at the least need CI checks to confirm all of this nix packaging logic continues to work and we will confirm with team that we want nix support in repository instead of elsewhere. I have opened #815 for discussion/tracking.

[cretz]

Actually, I think I misunderstood the purpose of this PR. Is this to make developing and building the CLI easier in nix and not related to publishing of a nix package? If so, we will discuss as a team if we want to incorporate this. We have traditionally followed normal Go projects here of just having the code and no distro-specific things so users can build Go code as they may with their own Go projects (just go build).

[secobarbital]

Thank you. It is indeed for development purposes. The nix package is already being maintained in nixpkgs so I am just pulling that and overriding the src to point to the local sources. As the development needs can deviate between projects, e.g. golang upgrades, different services, etc, it would be nice to just enter the directory and know that all the right tools are available at exactly the correct versions.

[secobarbital]

It will be much more useful for the server, where we can create a nix flake with services so you can start postgres, cassandra, mysql, elasticsearch, otel-collector without setup and without using docker which, as noted on the README, is slow on MacOS.

[cretz]

I am not sure any of the Temporal developers would leverage this and therefore it'd be a bit hard to maintain. Our goal is to be able to support go build the way traditional Go developers might regardless of platform. We're a bit hesitant to have platform-specific contribution helpers. Pardon my lack of nix knowledge.

As the development needs can deviate between projects, e.g. golang upgrades, different services, etc, it would be nice to just enter the directory and know that all the right tools are available at exactly the correct versions. [...] It will be much more useful for the server

The goal is to have it all self-contained so go.mod is used for versions and there should be no deviation. Granted that may be different for https://github.com/temporalio/temporal where there are separate services, but they are all together in this repo for the dev server.

Can you clarify a bit on how things are deviating when you're developing/building this? We're hoping it's nothing more than go build and if you need an updated server there is the next-server branch, but we still expect go.mod to define the versions of external dependencies, not local source overrides.

[secobarbital]

@cretz Thank you for taking the time to understand the purpose of this change. I use NixOS and nix-darwin myself, so I don't have go or any other language toolset installed globally, preferring to have a nix flake define the toolset and development environment for each project and direnv to automatically activate the environment upon entering each project directory.

While I believe there is a growing set of devs with this preference, I can of course understand if the Temporal community does not, especially given how nice and consistent the go ecosystem is compared to python and ruby. The server one might be more valuable with the services running natively on MacOS.

I'm happy to leave this here until you find value in it or feel free to close it if you don't think it is useful.

[dnr]

For what it's worth, I'm a Temporal developer and I use NixOS exclusively on all my systems. I do it like this:

Check out all Temporal repos underneath ~/temporal/

Put this in ~/temporal/shell.nix:

{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
  GOPATH = toString ./go;
  nativeBuildInputs = with pkgs; [
    go
    protobuf
    shellcheck
  ];
}

Put this in ~/temporal/.envrc:

use nix
PATH_add go/bin

The GOPATH parts are optional but I like keeping the Temporal stuff separate from any other Go projects.

This approach doesn't pin things as tightly as this PR, or build the cli as a Nix derivation itself, but actually I think those are benefits here: it keeps it closer to how other Temporal developers build things, and I get to take advantage of Go build caching (there are workarounds for this but they're not great).

Also, most changes to the cli are probably going to end up touching other Temporal repos too, so having a single solution that works across repos is nicer.

This PR pins the vendorHash for building the cli, which I think will be a big maintenance burden.

[secobarbital]

@dnr That's a great solution for taking care of all these go repos in one fell swoop! I guess the question for this PR is:

Do we want a one-liner setup for outside contributors who use Nix, given it does not interfere with the dev workflow of the rest of the contributors, but does introduce a couple of files that are not useful to those that don't use them.

@cretz I get why you consider this "platform-specific contribution helpers" and the concern about them. I can imagine the repo would be cluttered if we also added a guix.scm, a Brewfile, asdf .tool-version, etc. I will only add that I wish there was some one-liner setup for a new contributor rather than none.