Add nix flake

[happenslol]

This PR adds a nix flake to the repository. I was looking to contribute to this project, and since I'm mainly using NixOS at the moment, that required me to at least set up a devshell to pull in the dependencies for this project. I generally find it easier to just set up a flake, since that also allows me to build the project and integrate it into my system configuration.

Adding a flake would have a few advantages, even for non-NixOS users:

• Being able to jump into a devshell with all required dependencies installed
• Being able to run the app just with nix run github:wez/wezterm
• For NixOS users, being able to depend on specific versions of the app more easily

The setup here mainly follows the packaged version of wezterm in nixpkgs, especially when it comes to the build. The flake itself is very minimal.

Please tell me if this is something you would consider including. I can understand if you don't want to have this be a part of the project, but I figured I would just open a PR since I already created the flake for developing myself :-)

[wez]

Thanks for diving in!

I'm sorry to say that I don't want to add this to the repo: it appears to be mostly boilerplate from a system that I don't use and can't maintain, and that will drift out of date very quickly without someone actively maintaining it.

I would be more amenable to this if it wasn't adding more stuff at the top level of the repo, and if there was some kind of automation to validate that it continues to work and remain useful. However, without someone who knows and uses nix to monitor and maintain it, I would be inclined to delete it if it does fall into disrepair as I don't have the bandwidth to learn and follow nix.

[happenslol]

No worries, that's completely fair. While it would be possible to add scripts that automate some of the maintenance work, someone would of course need to maintain those scripts. So yeah, that doesn't really address the core issue.

Just a few notes to address the points you made:

• I would be open to maintaining this, but I can also understand that you would have to trust some random guy™ from github for this. I'm planning on working on a few other open issues and features for this project, so maybe I'll come back around to this once I've done that ;-)
• It's possible to stash away the flake configuration in a subdirectory, for example, neovim uses a contrib directory for this.
• It's of course possible to add CI steps that ensure the flake still builds, but I can imagine that you would want to avoid CI blocking changes because of a build system foreign to you not agreeing with them.

Thanks for the response, and feel free to close this. I'll keep depending on my fork for now then.

[gabyx]

@happenslol This is very valuable! Do you intend to update this PR?

• Would actually be a Dockerfile which boots NixOS and builds this flake, be enough to put it into the CI to verify that it builds?

[happenslol]

Hey, glad to know it helped someone! I usually rebase this around once every 1-2 months, whenever I update my own config. Usually all that's needed is to update all the flake inputs once, and then update then hashes that are produced for the dependencies during the build.

I think it's tough for the maintainer to accept adding these files if they don't use NixOS themselves, since it's out of their hands if they want to update something which causes the flake tests to fail, at which point someone knowledgeable would need to be in the loop for every release.
Maybe it's possible to have the flake in a different repo? I'm not sure if there's a good way to do that and keep it in sync with this, I'm open to suggestions.

[edmundmiller]

I don't think there's anything keeping the flake from living in a different repo. Just use a fetchGit.

Might be confusing if it's happenslol/wezterm-flake instead of just wez/wezterm but oh well 🤷🏻.

[wez]

To clarify: I'm ok adding the flake here if we can move the boilerplate out of the top directory, and if there is an accompanying workflow that verifies that it continues to work.

It seems like between the folks here and in #4286 there are enough interested and capable folks around to troubleshoot this.

While I don't want anyone to feel like they are permanently committed to maintaining this, I would appreciate having a short list of 2-3 people that are willing to troubleshoot failures in the flake CI.

[happenslol]

Good to know! I'll have time to update this and move it to a subfolder over the coming days. I'll probably just copy the approach that neovim is taking, I remember them having the flake in a subfolder as well.

I still think that it's important that flake CI does not block any merges, however.

[gabyx]

@happenslol : Cool, do you need a github worflow as well, I think its as easy as taking the centos one and replacing the container with nixos image and then just run a nix build etc?
We should make it a warning and not an error.

@wez : I feel the same, cluttering the top folder is never a good idea. Using side tools which force to have things in the top folder are just sheit... @happenslol : Hope nix works, but I am unsure about the xxx.url = ... part...

[wez]

Yeah, I'd like to have a separate GH actions workflow for this. It needs to fail if the flake stops working, otherwise the failure will be invisible. There's no automation that depends on the status of the workflow, it's just me looking at it.

[gabyx]

@happenslol : we should make sure we setup the shell such that we use the correct rust toolchain. I have the assumption thats nightly stable and rustftm with nightly:

I use the following inside flake.nix:

Update:

  inputs = {
    # Nixpkgs
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";

    # You can access packages and modules from different nixpkgs revs
    # at the same time. Here's an working example:
    nixpkgsStable.url = "github:nixos/nixpkgs/nixos-23.05";
    # Also see the 'stable-packages' overlay at 'overlays/default.nix'.

    flake-utils.url = "github:numtide/flake-utils";
    rust-overlay = {
      url = "github:oxalica/rust-overlay";
      inputs = {
        nixpkgs.follows = "nixpkgs";
        flake-utils.follows = "flake-utils";
      };
    };
  };

  outputs = {
    self,
    nixpkgs,
    nixpkgsStable,
    flake-utils,
    rust-overlay,
    ...
  } @ inputs:
    flake-utils.lib.eachDefaultSystem
    # Creates an attribute map `{ devShells.<system>.default = ...}`
    # by calling this function:
    (
      system: let
        overlays = [(import rust-overlay)];

        # Import nixpkgs and load it into pkgs.
        pkgs = import nixpkgs {
          inherit system overlays;
        };

        rustToolchain = pkgs.pkgsBuildHost.rust-bin.fromRustupToolchainFile ./rust-toolchain.toml;

        # Things needed only at compile-time.
        nativeBuildInputs = with pkgs; [
            rust-bin.stable.latest.minimal
            rust-bin.stable.latest.clippy

            rust-bin.nightly.latest.rustfmt
            rust-bin.nightly.latest.rust-analyzer
          pkg-config
        ];

        # Things needed at runtime.
        buildInputs = with pkgs; [openssl llvmPackages_15.lldb];
      in
        with pkgs; {
          devShells.default = mkShell {
            inherit buildInputs nativeBuildInputs;
          };
        }
    );
}

@wez what rust toolchain should one use to develop in this project?

[wez]

wezterm itself is built using the stable toolchain. However, when using rustfmt, we need the nightly toolchain.

[gabyx]

@happenslol I updated the file above to reflect wez answer.

[happenslol]

Alright, I've updated the branch to the latest upstream revision, and moved the flake to a subdirectory. I've also added the rust-overlay as you suggested in your code snippet, and set the versions for the toolchain.

I'm not too experienced with Github Actions, and I'm currently pretty busy, so I'm not sure if it makes sense for me to take care of that part as well. @gabyx: Do you think that's something you could work on? The flake builds as-is on my machine. You could open a PR for my branch, or I can give you collaborator permissions? Whatever you prefer.

[edmundmiller]

GitHub Actions are sadly in my wheel house.

Happy to contribute them just let know whether it's preferred to make a new PR to the main repo or a PR to the PR.

In the event I get pre-occupied and someone else wants to beat me to it https://github.com/DeterminateSystems/nix-installer-action and the other DeterminateSystems actions make it pretty simple.

[gabyx]

@emiller88 Happy if you could contribute in another PR. I am not so aware of the nix installer thing, I would probably have done it less proper in the sense that I would have uses a NixOs image ans just ran nix build… but thats probably not what we want. Better to go with the specific Github action to install it into ubuntu etc… I could tackle this with your help in a new PR if you like. Maybe you are just faster then me :)
I should finishe up another PR I got myself into : #4629 …

[gabyx]

Should we try to run a nix build on two systems for now? MacOs and Ubuntu?

[happenslol]

Thanks for working on this! I put a couple comments, don't take anything as a requirement, I'm just trying to give tips on stuff that stuck out to me during a quick read :)

Heya, thank you so much for your comments! I'm not super experienced on packaging in nix, so this is very appreciated. It might however delay getting this into a mergeable state. I hope that I'll have time to bring this up to speed over the coming few days, but I can't make any promises.

[ThinkChaos]

Yeah no worries, just thought I'd give a couple tips cause learning this stuff takes time if you don't have anyone to show you around :)

[gabyx]

@ThinkChaos Nice inputs! Reviews are always appreciated especially from more experienced folks! Thanks for taking the time!

[anthr76]

This is great work! I plan on testing this on the branch until it's merged

It's compiling now :) this is my input

    wezterm = {
       url = "github:happenslol/wezterm?dir=nix&ref=add-nix-flake" ;
       inputs.nixpkgs.follows = "nixpkgs";
    };

I just wanted to report wezterm is working great. Only one small nit I'm seeing currently. The desktop file appears to be missing

We may want to borrow some of this: https://github.com/NixOS/nixpkgs/blob/3dc440faeee9e889fe2d1b4d25ad0f430d449356/pkgs/applications/terminal-emulators/wezterm/default.nix#L94-L109

[ciarand]

I also just switched to this and it's great! One note: the nixpkgs version has the terminfo available as an installable derivation; it would be nice if this had that also. It looks relatively simple based on the nixpkgs version: https://github.com/NixOS/nixpkgs/blob/3dc440faeee9e889fe2d1b4d25ad0f430d449356/pkgs/applications/terminal-emulators/wezterm/default.nix#L130-L136

[happenslol]

Just as a heads up to anyone following this: I'm currently very busy and won't get to this until the end of the month, sadly. Just so we're clear on what's left to do here: I'll incorporate the review comments and fix the build on mac (although someone else will have to test that), and that should be it for the flake part itself.

@wez Do you want me to incorporate the CI changes here already? They're not coming from me, so I'd have to cherrypick from @edmundmiller 's branch. I think doing it in 2 PRs would be better, but it's up to you.

[deviantsemicolon]

I would love this because I can't use wezterm on hyprland right now(the issue was fixed in nightly), so this would be a great help

[anthr76]

I think it can't hurt if we merge this and iterate upon it. Although since @wez can't really review these someone else should be appointed reviews with codeowner or another similar mechanism.

[wez]

Yes please merge the CI changes into this PR so that I can review both together!

[wez]

Thank you!
Now, is there something that should be updated in the docs to help nix folks make use of this?

[happenslol]

Ah, I wasn't done with all the review comments yet, but it can't hurt to already have this in main so that people can use it without relying on my fork. I'll make another PR addressing the rest of the comments.

And yeah, it would be great for discoverability if the docs mentioned that there is a flake people can use. Basically, anyone with nix installed can now run wezterm simply by doing nix run github:wez/wezterm?dir=nix, and specific versions can be pinned in user installations. Development on NixOS is also now possible by using the devshell with nix develop ./nix inside the repo.

I'm still busy so I don't know if I'm the right guy to take care of the documentation - @gabyx @nekowinston @ThinkChaos you all had a hand in this, would any of you be able to take care of that?

[anthr76]

I will be happy to help as well! :)

[raphaelchristin]

Hey I just got into the nixos world and have been using wezterm nightly for a while. It is great software and I would very much like to install it as a flake into my system. Could someone point me in the right direction? My system configuration is set up as a flake already, so I assume that just adding this repo in the inputs would be the first step, but I am unsure where to take it from there. Any links to relevant documentation would also be great as I could not find any. Thanks in advance and apologies if this is not the right place to ask.

[sjcobb2022]

Hey I just got into the nixos world and have been using wezterm nightly for a while. It is great software and I would very much like to install it as a flake into my system. Could someone point me in the right direction? My system configuration is set up as a flake already, so I assume that just adding this repo in the inputs would be the first step, but I am unsure where to take it from there. Any links to relevant documentation would also be great as I could not find any. Thanks in advance and apologies if this is not the right place to ask.

Hi there @raphaelchristin

If you are using home-manager, you can do something like the following:

# flake.nix 
{
  inputs = {
    wezterm = {
      url = "github:wez/wezterm?dir=nix";
    };
  };
  # ... the rest of your flake
}


#some_other_file.nix that has access to inputs and pkgs.
{ inputs, pkgs, ...}: {
  environment.systemPackages = [ inputs.wezterm.packages.${pkgs.system}.default ]
}

If you are using home manager, still include your inputs, and then add it to your home manager config like so:

{ inputs, pkgs, ...}: {
  programs.wezterm = {
      enable = true;
      package = inputs.wezterm.packages.${pkgs.system}.default;
      # other config...
  }
}

[raphaelchristin]

Thank you so much! This seems to be all I needed, and is much simpler than I thought. Thanks to everyone and especially @wez for the great software!

[ppenguin]

If you are using home-manager, you can do something like the following:

@sjcobb2022 Thanks! Just wanted to try out wezterm for the first time (NixOS/Hyprland) and was surprised it didn't work out of the box.

Just as a small extra/alternative: you could also put it in the overlay, so it affects all HM users on the system:

nixpkgs.overlays = [
   (final: prev {
      wezterm =
        if (lib.hasAttr "wezterm" inputs) then
          inputs.wezterm.packages.${prev.system}.default
        else
          prev.wezterm;
   })
]

I've been using this paradigm to quickly switch between standard nixpkgs and dedicated (upstream) inputs by just commenting in/out the relevant inputs.

I'll probably be PR'ing a wezterm update to nixpkgs if I'm fast enough and find time 😉
I've been