Any interest in bringing this project under the NixOS organization?

[zmitchell]

Hi, I'm a member of the Nix Documentation Team. In one of our recent meetings (meeting notes) we discussed a tutorial about pinning, and the topic of niv came up. We currently aim to document stable, official interfaces, and while niv is stable, it isn't official. Is there any interest in making it an official project?

I personally don't have the authority to do so, but if there's interest from the maintainers I can at least get the ball rolling.

[SuperSandro2000]

Isn't niv immediately deprecated by flakes?

[zmitchell]

niv is deprecated

• if you can no longer use Nix without flakes
• whenever flakes are stabilized

[SuperSandro2000]

If people need dependency pinning they should use flakes. We shouldn't lure people into tools we know are going to be replaced rather sooner than later.

[nmattia]

@zmitchell thanks for bringing this up! I've been thinking about deprecating niv for a while (I'm using flakes myself) but it looks like people are still finding it useful.

[niv is deprecated] whenever flakes are stabilized

Do you know when that might be? Also I've heard some people do prefer niv's interface over flakes', so maybe there'll always be some use case for niv in that sense?

I'm definitely not giving niv much love at the moment, but I'd rather point users to an alternative tool (and deprecate niv officially) rather than creating confusion by having multiple "official" tools (niv & flakes). I've been confused in the past when there's been multiple official solution for e.g. packaging haskell, rust, python, etc and I think it hurts adoption more than anything else

[zmitchell]

There's an open RFC (not yet accepted) for a path to stabilization, so it could still be years before flakes are stabilized.

[SuperSandro2000]

[...] I'd rather point users to an alternative tool (and deprecate niv officially) rather than creating confusion by having multiple "official" tools (niv & flakes). I've been confused in the past when there's been multiple official solution for e.g. packaging haskell, rust, python, etc and I think it hurts adoption more than anything else

Couldn't have said it better.

[adrian-gierakowski]

thanks for bringing this up! I've been thinking about deprecating niv for a while

Until NixOS/nix#6530 is completed and officially released, flakes are basically unusable on projects utilising large monorepos so niv is still a very much needed piece of the ecosysem. So please do not deprecate it just yet.

[domenkozar]

https://devenv.sh/inputs/ uses that branch successfuly :)

[adrian-gierakowski]

https://devenv.sh/inputs/ uses that branch successfuly :)

amazing 🎉, so thers is light at the end of the tunnel 😃

although there do seem to be some issues still: cachix/devenv#331

[Dessix]

I noticed that this thread doesn't mention several of the other major limitations of Flakes which push toward our continued usage of Niv:

• Without Flake arguments NixOS/nix#2861 or Configurable derivations NixOS/nix#6583, Flakes are incapable of accepting parameters
  • Parameters remain necessary for CUDA scenarios and any hardware optimizations. The alternative is high combinatoric complexity of special-cases in the outputs, which are themselves limited by the non-laziness of attrsets.
  • All known workarounds invalidate the caching benefits which lead to the initial institution of this limitation.
• Flakes cannot modify their inputs prior to usage, e.g. with patches: Support flake references to patches NixOS/nix#3920
  • This leads to unnecessary forks of Nixpkgs and other repositories for single-change PRs, fragmenting the ecosystem and leading to flakes having stale inputs which are nontrivial to detect, where staleness is not dependent on the lock contents but the flake.nix file itself.

Experimental may not mean unstable, but Niv trivializes these scenarios, while Flakes - in their current incarnation - are extremely boilerplate-heavy and lack basic functionality required for hardware compatibility.

[bjornfor]

More reasons Niv isn't immediately deprecated by Flakes (IMHO):

• Nix Flakes cannot be used on airgapped systems: Nix Flakes is not usable without access to github.com NixOS/nix#8953
• Niv only emits Nix and JSON files, so using Niv today ensures forward compatibility forever. (With unstable Flakes you don't know when backward compatibility gets broken and old expressions cannot be used anymore.)

[SuperSandro2000]

• Nix Flakes cannot be used on airgapped systems:

There are easy workaround to fix this NixOS/nix#8953 (comment)

• using Niv today ensures forward compatibility forever

This is not right, as it is not right for flakes. nixpkgs can evolve over time and when using nix code from 10 years ago, it could be broken with flakes or niv.

One of the biggest problem with niv and all the alternatives is that people could do whatever in code and every repo is imported slightly different. If you wanted to use only one instance of nixpkgs, this always lead to chases through the code to find the next spot where a channel was imported that you didn't want to use or where to passthru nixpkgs/pkgs.

Flakes standardize that and I firmly believe that we do not make progress when adopting niv as official.

[bjornfor]

• Nix Flakes cannot be used on airgapped systems:

There are easy workaround to fix this NixOS/nix#8953 (comment)

Oh, somehow I missed that comment! Thanks for pointing it out.

• using Niv today ensures forward compatibility forever

This is not right, as it is not right for flakes. nixpkgs can evolve over time and when using nix code from 10 years ago, it could be broken with flakes or niv.

I don't understand what you're saying here. AFAIK, Nix expressions (and JSON) are very stable -- future Nix will sure be able to parse them. I'm not so sure about flake.{nix,lock} given their experimental status.

One of the biggest problem with niv and all the alternatives is that people could do whatever in code and every repo is imported slightly different. If you wanted to use only one instance of nixpkgs, this always lead to chases through the code to find the next spot where a channel was imported that you didn't want to use or where to passthru nixpkgs/pkgs.

Flakes standardize that and I firmly believe that we do not make progress when adopting niv as official.

I agree with Flakes having an advantage here, but it's marked as experimental. That means not ready for general usage. (Or should mean.)

I think Niv can be used until Flakes is stabilized without negatively affecting progress. In fact, I can see it having a positive effect, because it gives Flakes room to evolve freely in the experimental phase.