I'm not familiar with nix flakes, cc @krisajenkins (I remember mentioning you had done something like this) or @YPares are either of you able to review this? Is this something that needs to be checked into this repo or is there another canonical way to register nix flakes?

@agavra It doesn't need to, but it can be useful to have it locally (the point of Nix flakes is that any git repo can be its own "package registry"), as long as it can be properly maintained.

That being said:

@ysndr Note that tuicr is already flake-packaged in https://github.com/numtide/llm-agents.nix:

nix run github:numtide/llm-agents.nix#tuicr

(and I've been using it as a devshell to work on tuicr too)

The advantages is that it is automatically updated everyday by the llm-agents.nix CI, and that the builds are cached publicly ( https://github.com/numtide/llm-agents.nix?tab=readme-ov-file#binary-cache ).

Thanks @YPares for filling the picture.
Also I wasn't aware it's in numtide's flake. I couldn't find this project on nixpkgs and building it was straight forward enough.

Good thinking on the cache part though.

The way I see it if this project wants to encourage nix users, these are the options:

• add instructions to use numtides flake
• upstream into nixpkgs, and add instructions
• add a local flake and instructions (this pr)

Any combination of these (or none of them) are a valid choice.
Personally I'd appreciate a local flake for dev purposes and discorevability. Up to you @agavra if you think that's interesting at all -- remains totally optional as you can see.

That said, if you want to go forward with this PR I'd need to drop the result link and add result to the .gitignore

👍 let's add instructions to use numtides flake but we can also keep the local flake as well. Thanks for chiming in @YPares

Ok :)
The only thing in the PR I'm not up to speed with is naersk, which I haven't used myself. What advantages does it bring compared to the usual rustPlatform of nixpkgs?

naersk

The main benefits are

• And dependency parsing without IFD (import from derivation) or FOD which should make maintainance easier as the package wont need updates together with cargo deps.
• it's dependency caching, i.e. building crate dependencies first, requiring only rebuilds of the root crate. This speeds up repeat builds (esp when combined with CI, but thats deeper than this PR intends)

It fairly common alternative, along with crates2nix (better caching more overhead for cargo dep changes).

If you prefer vanilla nixpkgs I can throw naersk out as well.

@ysndr No it looks simple enough :) thanks for the answer!