Add nix flake support

[ryuheechul]

Currently I don't see src-cli is listed at https://search.nixos.org/packages, it would be nice to be able to install via Nix.

In the meantime, adding these nix files into this repo directly will allow installing via nix flakes similar to how it's done at https://github.com/ryuheechul/hexto256/blob/main/flake.nix.

Installation has been tested with a usage like this one, ryuheechul/dotfiles@4e7fb91.

Test plan

(added by @Strum355)

It was tested manually, and is not part of any critical path

[mrnugget]

Tagging our Nix experts here :)

[keegancsmith]

LGTM, nix build worked for me. One inline comment about removing default.nix. We should probably follow-up with running nix-build in CI to prevent it breaking.

[keegancsmith]

TBH I'd remove default.nix and just rely on flake.nix. Then we can remove this input.

[ryuheechul]

@keegancsmith I'm curious, what would be a downside of keeping default.nix to be compatible with non-flake nix usages? I haven't come across this topic yet so I would like to hear what you think and I can add my thoughts on that too if that's ok.

[Strum355]

Im personally indifferent to this, but we're not using flake-compat in our main repo either (I believe we should all be using flakes and leaving the old ways behind :p )

[Strum355]

Would love to have this, my main concern is whos going to keep it up-to-date. Itd need updating every time we bump sg/sg dependency.

Alternatively I'm wondering whether we should use gomod2nix here instead? I dont really mind either way as im not overly affected, but it may be a tad more nix-y to have the deps individually entered into the store, but it does add an extra cli step (which is already necessary with vendor checksum, so im not sure what we should do 🤷 )

[ryuheechul]

@keegancsmith about adding the build in CI, I just tested and you can see the result here - https://github.com/ryuheechul/src-cli/actions/runs/4611207337/jobs/8150611019. What do you think? Also would it be good idea to have this test already if nix build is not officially supported? Because broken build could annoy maintainers if they don't care about nix build.

---

@Strum355 I think those are legitimate concerns and should be addressed for a long term viability.
Maybe a lightweight approach like what Neovim does would be a good idea?

My assumption of that model is followings:

• basically keep it in the repo but mark it as contrib(uted) - kind of like an extension point
• which allows some use case like this one, https://github.com/nix-community/neovim-nightly-overlay
• and even if core members don't maintain this, anyone who uses the flake to install this would notice the breakage and patch the fix to scratch their own back, I hope!

Therefore the burden can be contained in reviewing part only (at least as a start)

[Strum355]

@keegancsmith about adding the build in CI, I just tested and you can see the result here - ryuheechul/src-cli/actions/runs/4611207337/jobs/8150611019. What do you think? Also would it be good idea to have this test already if nix build is not officially supported? Because broken build could annoy maintainers if they don't care about nix build.

I would probably not have that, as you mentioned because maintainers mightnt care about the nix build. I wish they would, i wish everyone at sourcegraph used nix, but thats not the case today 😄

@Strum355 I think those are legitimate concerns and should be addressed for a long term viability. Maybe a lightweight approach like what Neovim does would be a good idea?

My assumption of that model is followings:

* basically keep it in the repo but mark it as contrib(uted) - kind of like an extension point

* which allows some use case like this one, [nix-community/neovim-nightly-overlay](https://github.com/nix-community/neovim-nightly-overlay)

* and even if core members don't maintain this, anyone who uses the flake to install this would notice the breakage and patch the fix to scratch their own back, I hope!

Therefore the burden can be contained in reviewing part only (at least as a start)

That seems reasonable to me, I hate to have something that will regularly not work, but people can always pin to a known working version at least 🙂

[ryuheechul]

@Strum355 thanks and applied the suggestions and tested it via code below!

let
  rev = "nix";
  url = "https://github.com/ryuheechul/src-cli/archive/${rev}.tar.gz";
  tarball = fetchTarball url;
  at-contrib = tarball + "/contrib";
in
(import at-contrib).default

So when it's merged, people can do any of the examples below.

# without flake
let
  rev = "main";
  url = "https://github.com/sourcegraph/src-cli/archive/${rev}.tar.gz";
  tarball = fetchTarball url;
  at-contrib = tarball + "/contrib";
in
(import at-contrib).default

or

# with flake
{
  description = "src-cli flake";

  inputs = {
    # ...
    src-cli.url = "github:sourcegraph/src-cli?dir=contrib";
  };

  # ...
}

or

# as a command
nix shell 'github:sourcegraph/src-cli?dir=contrib' -c src

[Strum355]

@burmudar how 2 make go-test action run

[burmudar]

@burmudar how 2 make go-test action run

Hmmm it's not triggering because it's a fork. I'll see what I can do

[burmudar]

@ryuheechul Could you please rebase once #970 is merged. It should fix the stuck action we're seeing on your PR 🙏🏼

[burmudar]

Thanks for your contribution @ryuheechul!