[Feature] NixOS support

[senseab]

Problem Description

I'm always frustrated when I have to manually build ferrite from source or rely on unofficial, community-maintained Nix packages to use it on NixOS. Currently, there is no official Nix packaging support for ferrite, which means NixOS and Nix package manager users cannot install, manage, and deploy ferrite in a declarative, reproducible, and system-native way. This creates unnecessary friction for Nix-based users: manual builds lack version locking and dependency consistency, while unofficial packages often lag behind upstream releases, contain unvetted changes, or break with NixOS system updates.

Proposed Solution

Add official, maintained Nix packaging support for ferrite, with the following core deliverables:

1. Add a flake.nix file and supporting Nix expressions to the upstream repository, providing a standardized, reproducible way to build, run, and develop ferrite via the Nix package manager.
2. Maintain cross-architecture compatibility (x86_64 and aarch64, where applicable) for NixOS and standard Nix workflows across Linux and macOS.
3. Integrate Nix package builds into the project's CI/CD pipeline to validate build correctness with every release and code change, preventing regressions.
4. Work towards upstream inclusion of the ferrite package in the official Nixpkgs repository, with the project team overseeing version updates and compatibility fixes.

This will allow Nix users to install and use ferrite directly from the official upstream source, with full support for declarative system configuration, version locking, and reproducible environments.

Alternative Solutions

1. Manual local build from source: Users can clone the repository and build ferrite manually, but this requires manual dependency management, cannot be integrated into NixOS's declarative system configuration, lacks version rollback capabilities, and creates inconsistent environments across machines.
2. Unofficial community Nix overlays/flakes: Third-party community packages exist for many tools, but they are not maintained by the upstream ferrite team. This leads to delayed updates for new releases, potential security risks from unvetted modifications, and compatibility issues with NixOS version updates.
3. Cross-distribution package managers: Users can install ferrite via other package managers (e.g., cargo, brew) on NixOS, but these do not integrate with Nix's declarative system management, break Nix's reproducibility guarantees, and can cause dependency conflicts with system packages.

Use Cases

Describe specific scenarios where this feature would be useful:

1. When NixOS users want to declaratively install ferrite alongside other system packages via their configuration.nix or home-manager config, with consistent versioning and rollback capabilities across system updates.
2. When developers want to spin up a temporary, reproducible ferrite environment with a single nix shell command, without needing to install dependencies or modify their system globally.
3. When users need to run the latest version of ferrite directly from the upstream repository on any Nix-supported system, with a single nix run command and no manual build steps required.
4. When teams use Nix for CI/CD pipelines, and need to include ferrite in their automated workflows with guaranteed reproducibility across different build environments.
5. When users manage multiple Nix-based machines, and want to sync the exact same version and configuration of ferrite across all devices via a shared flake config.

Mockups / Examples

Example 1: Direct run via official flake

Users can run the latest version of ferrite without permanent installation:

nix run github:ferrite-project/ferrite

Example 2: Declarative installation on NixOS

Users can add ferrite to their system configuration via the flake input:

# flake.nix
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    ferrite.url = "github:ferrite-project/ferrite";
  };

  outputs = { nixpkgs, ferrite, ... }: {
    nixosConfigurations.my-machine = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        {
          environment.systemPackages = [ ferrite.packages.x86_64-linux.ferrite ];
        }
      ];
    };
  };
}

Example 3: Temporary development shell

Users can enter a shell with ferrite available for one-off use:

nix shell github:ferrite-project/ferrite

Reference Examples

Many popular open-source projects provide official Nix flake support, including:

• Helix Editor
• Neovim
• Lapce

Additional Context

NixOS and the Nix package manager have a rapidly growing user base, with a strong focus on reproducible, declarative system management. Official Nix packaging will significantly expand ferrite's reach to this community, while also providing a consistent, low-friction installation path for existing users on Nix-based systems.

Maintaining an official flake has minimal ongoing overhead for the project team: Nix's built-in dependency management and lockfile system handle most version updates automatically, and CI integration can ensure the package remains buildable with every commit. Additionally, official upstream packaging eliminates the risk of users running modified, unvetted versions of ferrite from unofficial community sources, improving overall user security and experience.

The Nix community is also willing to provide support and reviews for the initial packaging implementation, to ensure compliance with Nix best practices.

Priority

How important is this feature to your workflow?

• Critical - blocking my work
• High - significant improvement
• Medium - nice to have
• Low - minor convenience

[OlaProeis]

Thanks for this incredibly thorough and well-researched feature request! The level of detail here - from the use cases to the flake examples and reference implementations - is really appreciated.

I think this is a great idea. NixOS has a growing community and reproducible builds are valuable. A few thoughts:

1. Flake in the repo - Having a flake.nix maintained upstream makes sense. Since Ferrite is a Rust project, we can leverage crane or naersk for the Nix build derivation, which should keep maintenance overhead low.

2. CI integration - We'd want to add a Nix build check to our CI pipeline to catch breakage early.

3. Nixpkgs submission - Once we have a stable flake, submitting to nixpkgs as a follow-up would be great.

Would you be interested in contributing an initial flake.nix implementation? Given how well you understand the Nix ecosystem, a community-contributed PR would be very welcome. We'd be happy to review and iterate on it together.

If not i will look into adding this to the 0.2.7 Roadmap, expected release next week.