Hacker News Reader

Comment by setheron | Hacker News Reader

I'm still in the 'meh' camp for flakes. I use niv and it gives me enough usability.

I find the need to include additional libraries to make flakes usable for some reason a weird hurdle I don't personally enjoy (i.e. flake-parts or systems)

View on HN

The thing I actually love about Flakes is the fact that my immutable system configuration now also contains the versions of dependencies, instead of them being in some out-of-band special area. This is super nice for rollbacks and just general visibility.

It's even more of a plus that it is aware of Git and makes rather surprisingly intelligent decisions when automatically upgrading the system on a schedule (as one example, it seems to be able to deal with when the Git repository has staged or unstaged changes just fine, producing commits with just the lockfile changes.)

Except that niv doesn't ensure pure evaluation, and thus a number of non-flakes, niv-friendly projects are unusable with flakes, and are often difficult to work with otherwise due to their impurities.

It also can't do transient overrides which is quite literally the essential reason that Flakes is killer to me.

For example, I can cross-compile to riscv64-linux, including a bunch of 3rd party flakes repos *specifically* because I refer to them and then override their nixpkgs to point to my nixpkgs with various cross-compilation fixes.

Definitely not possible to do this with niv.

It also does nothing to solve the countless issues with channels that I've watched afflict countless new Nix users, every week, for 3+ years. [insert the usual 8-stop troubleshoot list when a user has any issue possibly related to channels]

I tend to just override nixpkgs downstream. I think the situation you are describing is more power-user.

Flakes to me introduced a lot of overhead beyond what niv can provide.

I get 99% value just pinning my top level dependencies since most of the time I'm referring nixpkgs + 1-2 other packages.

Niv is fine and good but there's a lot that it will never provide, like the ability to `nix run` packages or `nix flake show` what your project provides with only a URL in hand.

You can still `nix run` packages using niv -- no clue what you talking about.

You can also just look at the niv sources.json file pretty easily if you knew the URL. Rather trivial command to run.

I don't find the above compelling (or correct?)

nix run github:DeterminateSystems/flake-checker

What's the Niv equivalent of this?

# non-flake $ nix run -f https://github.com/fzakaria/mvn2nix/archive/master.tar.gz --command mvn2nix

# flake $ nix run github:fzakaria/mvn2nix#mvn2nix

mvn2nix is a flake, though. How would I run a project that uses Niv and isn't a flake?

I actually support both by having default.nix

At this point I recommend we take this through another medium like email or feel free to open up a discourse to help fill in the knowledge gap. Feel free to tag me on it.

The -f is for 'file', and when you point it at a directory or repo/archive path, it resolves to a default.nix file rather than a flake.nix file.

I moved to npins which has slightly more features that niv.

But niv has been great, I wish we can have patching natively so all my tons of patches can be bolted on faster.

Luckily, you can still use niv! I still am for certain projects. It works so well for what it does. Flakes give a little more ofc.

You absolutely do not need flake-parts.

What is it even? I see it referenced now and then and don't understand in what situations it would be useful.

It adds a module system to nix flakes. I've been using nix every day for 4 years and make heavy use of flakes but TBH i'm not really sure the benefit flake-parts. It looks like a ton of new boilerplate.

Reply on news.ycombinator.com