[Tracking Issue] Nix 2.3 parity

[RaitoBezarius]

This tracking issue has the ambition to track all known Nix 2.4+ regressions that were either reported in this tracker (or to create them if they were not reported yet.)

Discussion came again in the Nix systemd channel about our reliance on Nix 2.3, for which we don't have good solutions in nixpkgs except the one of keeping it. Maintaining Nix 2.3 is hard for the people who are relying on a daily basis (including myself).

@ElvishJerricco and @Ericson2314 advised me to create this tracking issue to see if we can solve this once and for all.

• Nix remote build coredumps when mixing nix versions #4664
• fetchTarball regression in nixUnstable? #4785
• builtins.fetchGit regression in 2.4 when coming from 2.3 #5128
• Make it possible to only build derivations with preferLocalBuild locally. #5646
• nix command broken: massive slowdown, requires flakes-specific experimental flags on non-flakes systems #5637
• Temporary build directories not cleaned up because they are not empty #5207
• Tools barf on invalid (empty name) store paths, without telling me where they are referred to #6090
• nix-instantiate uses «repeated» instead of <CYCLE> when printing #8671
• "error: path '/nix/store/...' is not valid" when saving a reference to a store path in $out in a fixed output derivation #5509
• Decreased instantiation performance with daemon-store #6309
• [regression] error: chmod operation not permitted #6765
• an extra issue unfilled is the missing progress bar in the nix repl without flakes
• an extra issue ~filled is the Ctrl-C broken behavior: Various Nix commands ignore Ctrl-C (SIGTERM) #7245

If you advise ditching the old nix search and to use the experimental feature, please mind:

• nix search with -f '<nixpkgs>' lacking attribute names / package names from results #5641
• nix search with -f works poorly with "installable" semantics #5642

It would be nice if the tests also didn't run only with flakes and nix-command BTW as seen in

nix/tests/init.sh

Line 20 in b367f10

experimental-features = nix-command flakes

.

Involved stakeholders

cc @andir @alyssais @tazjin @flokli and certainly other people I am forgetting.

Priorities

Add 👍 to issues you find important.

[ghost]

• Versions of Nix >= 2.4 disappear from nixpkgs frequently #9419

[tomberek]

I've gone through and added comments, reviews, and hopefully gave productive suggestions for various items. It would help to have the list above prioritized. Some items can indeed be hard-blockers, some are disagreements with explicit decisions, some would be hard PRs to debug/discover/solve (but non-controversial to merge), some interact with other Work-In-Progress, and some are unclear about the required next steps.

The Nix team does triage and review twice a week. I've added the fetcher related items to the queue for review next as we've stated that fetchTree and related (including fetchGit) are the current priority. I suspect we will cover store layer items next like repair.

To help clarify a few items, I've added comments about a few that still need an explicit decision communicated made to help communicate what direction we are going in. This should be better than an implied decision or one not stated clearly.

[Ericson2314]

I have a number of old PRs relating to trying to test 2.3 <-> master RPC in both combinations (older client, newer client). It would be great to finish those but I could use some help with that.

A good place to start is 2.3-maintenance...Ericson2314:nix:2.3-macos-eof a backport of #8049 that is needed so I can tighten up the test suite (which cause more of these sorts of failures to be caught). The tightened test suite is in turn needed to make the cross version test suite adjustments feasible.

That links branch does not work because of some other difference between 2.3 and newer Nix (a file descriptor is unexpected closed at one point).

[roberth]

2.3-maintenance...Ericson2314:nix:2.3-macos-eof a

@Ericson2314 Do you want to make a PR for this?

[ghost]

So, @RaitoBezarius, we have a problem here that you're using an issue in the Nix repository to track what is in large part a nixpkgs problem.

@roberth pointed this out when closing the issue I opened. He's right, but this also means that this issue you've created here is not addressing

our reliance on Nix 2.3, for which we don't have good solutions in nixpkgs except the one of keeping it

... so if that is what you are trying to address, an issue in the Nix repository is not going to be successful. Or relevant to that goal, really.

Carry on,

[roberth]

This issue is valid for this issue tracker, for the purpose to

track all known Nix 2.4+ regressions

I don't see how the listed issues would be in large part a Nixpkgs problem. If you think more should be done about 2.3 in Nixpkgs, feel free to track it there.
For most of the issues listed, I don't see how Nixpkgs could solve them (without patches, which would be bad).

[Ericson2314]

2.3-maintenance...Ericson2314:nix:2.3-macos-eof a

@Ericson2314 Do you want to make a PR for this?

Sure: done in #9495 anyone that can debug this I would greatly appreciate it!

[ghost]

Nixpkgs counterpart is

• [Tracking Issue] Nix 2.3 parity nixpkgs#271320

[ElvishJerricco]

@amjoseph-nixpkgs Please explain yourself

So, @RaitoBezarius, we have a problem here that you're using an issue in the Nix repository to track what is in large part a nixpkgs problem.

the issue is explicitly about nix-the-tool regressions. I do not see where you're getting nixpkgs vibes from. Your "counterpart" issue on nixpkgs is similarly lacking in explanation.

[ElvishJerricco]

Actually there's two issues you opened. They are similarly frustrating and lacking in explanation, so my comment stands.

[JulienMalka]

Here is one regression I am facing: #4813
Still documented as working here: https://nixos.org/manual/nix/stable/command-ref/nix-build