WIP: Recreate the Nix flake #54

Solves #29

I should remove the dockerfiles that have been restored reverting the original commit

#54 (comment) is solved

Couple of issues to investigate for now:

• We most likely need to provide a working rust environment to install extensions (i didnt run into this issue because i have a rust toolchain installed on my user)
• I've had to run rustup target add wasm32-wasip2 on my host in order to install extensions. Maybe adding cargo-wasi in the runtime dependencies could help, but im not too sure.
• #58
• I'm not sure what the names binaries that are exported should be. Right now they are gram and gramitor, a funny artifact of me replace zed with gram. I decided to leave it in, maybe you don't. lmk.
• Write docs on how to use the flake and build Gram using nix.
• #54 (comment)
• Try on aarch64-linux
• Try on x86_64-darwin
• Try on aarch64-darwin
• Upstream !54 (commit 163903e3d9) and revert to original repo

I just pushed an fix for GRAM_UPDATE_EXPLANATION: I updated the documentation and renamed it to GRAM_NO_BUNDLED_UNINSTALL since the only thing it does in Gram is to remove the bundled uninstallation script. So the Nix build should set that environment variable to something like "Use nix to uninstall gram".

We need help trying this on aarch64 and darwin if possible.

In !54 (commit 163903e3d9) I changed the tree-sitter-sql url to my fork, CI was failing because there is a reference to the README file in Cargo.toml but not in the crate's actual branch (https://github.com/DerekStride/tree-sitter-sql/tree/gh-pages)

I should open a PR to upstream the change, this is what we have in the meantime.

Looking good from what I can see, which admittedly is just surface level. Haven't used Nix much at all, but I am interested in learning to use flakes. Anyway, great work!

Thanks! I've fixed some things and I've told the CI to do its thing. We'll see. Either way there's a bunch of stuff I want to polish before getting this out the door (unless you're willing to merge an unfinished package and work on more complex fixes in another PR, your call). I still need to review everything before I give my green light.

No rush! I would like to give it a go at testing it myself too before merging, and I have at least one fix I am working on before I will start thinking about another release or anything like that.

I added this to main which I think can be useful for nix to get a reproducible build: 70a8786f79

tried to build on darwin_x86-64 , did not succeed

error: builder for '/nix/store/v6svdn4hvm51vvbf26az8myzg40b8l48-gram-editor-1.0.0-dev.drv' failed with exit code 1;
 last 25 log lines:
 > installing /nix/var/nix/b/070j7m9gfgf5i4p73vz1x2qndg/source/target/release/gram in postBuildInstallFromCargoBuildLogOutTemp9xS/bin
 > searching for bins/libs complete
 > buildPhase completed in 15 hours 42 minutes 34 seconds
 > Running phase: installPhase
 > /nix/var/nix/b/070j7m9gfgf5i4p73vz1x2qndg/source/crates/gram /nix/var/nix/b/070j7m9gfgf5i4p73vz1x2qndg/source
 > ++++ command cargo bundle --profile release
 > Bundling Gram Dev.app
 > Finished 1 bundle at:
 > /nix/var/nix/b/070j7m9gfgf5i4p73vz1x2qndg/source
 > stripping references to Rust toolchain
 > Rust toolchain at: /nix/store/1blgpp80g2y3in03zy38mjjj7wfvmmyv-rust-minimal-1.93.1
 > stripping Rust toolchain references done
 > stripping references to cargoVendorDir from:
 > /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev/Applications/Gram Dev.app/Contents/Info.plist
 > /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev/Applications/Gram Dev.app/Contents/MacOS/cli
 > /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev/Applications/Gram Dev.app/Contents/MacOS/gram
 > /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev/Applications/Gram Dev.app/Contents/Resources/Gram Dev.icns
 > stripping references done
 > installPhase completed in 5 minutes 4 seconds
 > Running phase: fixupPhase
 > checking for references to /nix/var/nix/b/070j7m9gfgf5i4p73vz1x2qndg/ in /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev...
 > patching script interpreter paths in /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev
 > stripping (with command strip and flags -S) in /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev/bin /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev/Applications
 > ERROR: noBrokenSymlinks: the symlink /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev/bin/gram points to a missing target: /nix/store/ijy2p2sgk92yf9vlw6p4d4nfkh2r24ck-gram-editor-1.0.0-dev/Applications/Gram.app/Contents/MacOS/cli
 > ERROR: noBrokenSymlinks: found 1 dangling symlinks, 0 reflexive symlinks and 0 unreadable symlinks
 For full logs, run:
 	nix log /nix/store/v6svdn4hvm51vvbf26az8myzg40b8l48-gram-editor-1.0.0-dev.drv

built with nom build .
unfortunate that it failed in the fixup phase lol , means the build completed after like 15h48m18s , and failed right at the end , so sad .

macOS 15.7.4
MacBookAir6,2

Most of the nix build is setting the RELEASE_CHANNEL to dev which names the app Gram Dev.app, but it looks like at least some part is using Gram.app as the app name.

Personally I think the right fix is to keep RELEASE_CHANNEL set to stable and use Gram.app throughout, but I'm not sure which bits are intended for a flake dev environment and what is meant to be able to install on NixOS.. maybe the right approach would be to use dev for the flake and stable for a NixOS build.

About extensions: I think we can also provide a mkGramExtension helper to package them, then install via a home-manager module that install symbolic links and updated index.json to user_data_dir/extensions.

Just used this to build main (at 422df2edcf), had to nix flake update to update latest Rust from the oxalica overlay to 1.95.0, as now required by rust-toolchain.toml

This also brought cargo-edit to 0.8.4, which conflicts with the generate-licenses version check introduced by 642cd3ada9. Pinning to 0.8.2 isn't strictly necessary, it seems like 0.8.4 fixed the issue introduced in 0.8.3. Locally I set it back to CARGO_ABOUT_VERSION="0.8" but might be good to have a slightly more involved check to error/replace if 0.8.3 specifically is being used.

Cargo also wanted to run with --offline instead of --locked but not sure what that actually ended up modifying.

edit: pushed those changes to https://codeberg.org/f0x/gram/commits/branch/restore-nix

I will, again, argue that a nix package is unnecessary here. I would rather we add gram to nixpkgs, see PR.

Why? Because if gram decides to update libwebrtc, for example, you'd need to vendor in a build for it since it takes some time for nixpkgs to get an updated library version. This means that either you have to randomly add and then remove vendored code from nixpkgs from time to time or have your nix package not build sometimes. If you can't guarantee that the nix package builds than it's not much better than just overriding the nixpkgs package with the newer source

I'm all in for having a devshell, though

@WeetHet wrote in #54 (comment):

I will, again, argue that a nix package is unnecessary here. I would rather we add gram to nixpkgs, see PR.

I don't think these are mutually exclusive, flake/nix in repo for development or bleeding edge, in nixpkgs for stable packaging. And if you're publishing this as a flake, you might as well expose the built packages, instead of just the dev shell environment?

Why? Because if gram decides to update libwebrtc, for example, you'd need to vendor in a build for it since it takes some time for nixpkgs to get an updated library version. This means that either you have to randomly add and then remove vendored code from nixpkgs from time to time or have your nix package not build sometimes. If you can't guarantee that the nix package builds than it's not much better than just overriding the nixpkgs package with the newer source

Because of this, project-specific version will likely use tooling that's closer to the language ecosystem, ie Crane which just reuses the Cargo-lock.toml without pinning hashes, whereas the nixpkgs package would use buildRustPackage?
Though take these comments with a grain of salt, since I don't have much experience with flakes specifically, nor Rust.

also libwebrtc specifically is a bad example, as all the livekit stuff in zed was removed from gram? but I get your point

Alright, I'll keep it as is as it does technically work but I don't have the will to continue working on this. The derivation (again, this is pulled from zed) is insanely complex for no reason, and makes honestly weird choices. I also don't have enough time to work on making my own flake from the ground up. Wouldn't surprise me if this is all slop to begin with. There's also a much more sensible PR in nixpkgs that's only blocked by the staging cycle, so it's really not worth the effort imo.

If someone wants to work on this, I'll happily let them do it, but I have no desire to work on this letter soup anymore.

Any updates?

@krig, is the PR can be closed?

For the record:

• If no one else wants to pick up, my partner @tasiaiso has already stated she won't continue work on it due to the flake's unnecessary complexity
• Nixpkgs now has an upstream gram package

So, if you're just looking for Gram on nixOS, that's the way-to-go. I may ask tasia to close the PR herself unless someone else wants to step up and continue work on it

I'll close it now, since if you really want to make a flake, i recommend starting from scratch instead of using this code.

Hi, thank you @tasiaiso for giving it a go :)

I have countless branches with failed attempts at fixing stuff lying around for this code base...