nixVersion.nix_2_3: Remove #204371
nixVersion.nix_2_3: Remove #204371
Conversation
github-actions
bot
added
6.topic: nixos
ofborg
bot
added
8.has: clean-up
10.rebuild-darwin: 0
|
Sounds good to me, let's also bump minver (i will handle it in #203361 which we can merge when most people have migrated to 22.11) |
|
The minver bump is already in there, but your rationale sounds better, so let's take yours. What about the remaining packages in |
let's think about that in #203361 this pr can be merged with the minver bump and the release notes and i'll remove them in my pr |
|
@andir why the 😕 ? |
2.6 is there quite newly: PR #200357 |
|
I'd personally not bump minver at this point. Maybe print a warning, but not hard error. I mean, everything will still work fine with 2.3, except perhaps downloading from cache.nixos.org – and only for binaries created in future (and it's not like switch's been decided yet). So at this point, bumping minver feels like introducing breakage without utilizing any benefit in exchange (in nixpkgs). |
|
Ok with dropping pythonix |
mweinelt
force-pushed
the
drop-nix-2-3
branch
from
b916fe7 to
a9f2fb7
Compare
|
Dropped the minver bump. |
Because I am still using 2.3 daily. I've had it as a default until last week. Newer Nix versions simply break too much for me to be happy with them. Reporting issues to the Nix project usually doesn't result in any constructive conversation on how to fix issues. PRs are left hanging etc. If you asked me, all versions after 2.3 are at best beta quality. |
|
The default nix version is newer than 2.3 for quite a while and no one I know in person has problems they complain about it that weren't also in 2.3 like to much RAM usage, downloading could be faster or taking a bit to evaluate. I'd rather fancy zstd compressed packages to slightly speed up downloads and improve extraction performance than keeping nix 2.3. |
|
I know at least half a dozen people who have nix pinned to 2.3. Nix 2.3 was the last “stable” release (the release window between 2.3 and 2.4 was over 2 years), before promises like “the new CLI is gonna be stabilized any week now” were traded in for “flakes is gonna be stabilized any bi-monthly release now”. What we effectively got since 2.3 was constant beta-quality changes to experimental features, which is the reason so many people stayed on 2.3 from what I know. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
I switched to later versions of Nix, but to be honest, I still run into Nix 2.3 regressions in the latest versions. I completely understand why some people want to keep running it, so I am not too keen on seeing this PR being merged until a clear plan of addressing Nix 2.3 regressions is there and executed (easier to say than to do, of course). |
alyssais
added
the
2.status: merge conflict
This package depends on pythonix, which has been archived upstream. The pythonix package depends on nix<2.4 and since nix 2.3 is going to be removed it cannot be supported anymore.
Pythonix is not compatble with nix>2.3 and since we plan to remove nix 2.3 it cannot be supported any longer.
Nix 2.3 is the last version not using libarchive for decompression and therefore prevents us from migrating the compression algorithm used for the binary cache.
Artturin
force-pushed
the
drop-nix-2-3
branch
from
a9f2fb7 to
c9d3cda
Compare
ofborg
bot
removed
the
2.status: merge conflict
|
zstd decompression support for Nix 2.3 isn't a lot of work; I'm not sure I understand why that option wasn't taken more seriously. I've implemented it in NixOS/nix#9221, aiming for simplicity over performance. |
|
Because it is already implemented via libarchive and we don't need to redevelop it for a 15 (!) minor version old release. Can we work together to get this PR finished instead of walking in circles? I am personally like many others using a version which is a lot newer and it's useable. Maybe things are broken but I don't have the comparison, I don't know but I want to get this somewhere because German Internet is slow and downloading less for every nixos-unstable bump would be a pretty great benefit. |
|
Yes but it's used by other people and any further version still possess
unsolved bug unfortunately.
Le lun. 23 oct. 2023, 19:28, Sandro ***@***.***> a écrit :
… Because it is already implemented via libarchive and we don't need to
redevelop it for a 15 (!) minor version old release.
—
Reply to this email directly, view it on GitHub
<#204371 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACMZRE2K5H5D32Q4KIB42TYA2ZLNAVCNFSM6AAAAAASTAH6IWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZVG43TKMJRHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
You'd download more with zstd, this was explained in the Discourse post. So it would worsen the situation. It'd only benefit people like me with fast French Internet. Under the presence of zstd in 2.3, removing it is NACK from me. |
I'm sorry to hear that. We've been putting in a lot of effort over the past year (the Nix team). In particular we've succeeded at keeping PR backlog stable near 300 until approximately NixCon. In other words, new PRs had a good chance, and those that didn't were compensated by old PRs. |
Newer Nix versions are full of regressions, so I'm still running 2.3 and expect to continue doing so until Tvix is production-ready. No work on your part is necessary to port it to 2.3, the code is already written, so I'm not sure what else would satisfy you. I don't mean to blame the Nix core team here either: 2.3 was an undermaintained mess of a codebase at best in a stable equilibrium of bugs, with little test infrastructure or code hygiene practices, that then got a heap of features and changes piled onto it without real-world exposure. What was shipped as 2.4 simply contained too many previously-unreleased changes at once. The Nix core team is doing their best, and I applaud their efforts. That said, I still consider 2.4 and up essentially beta versions.
This sounds like… opposition to zstd, rather than support for it? Decompression speed is fundamentally at odds with reduced bandwidth use. I'm not sure I understand anyone's motivations here at this point, and could use clarification. |
|
More generally, is there a tracking issue for moving Hydra to zstd? I'm actively working fulltime on cache storage size reduction strategies, and serving the cache as zstd would definitely help enable the techniques we're working on gathering data for. Further down the line, we would be able to reduce bandwidth use by serving through the same protocol we're working on for storage. |
|
I don't think there is. The place would most likely be https://github.com/NixOS/nixos-org-configurations/issues but I believe that right now the more pressing matters are like reducing storage size, which goes against this. Though perhaps we could afford worse compression ratio once we start expiring some older paths: NixOS/infra#282 |
You are just saying that without any context or referencing any issue(s) or problems. We have nothing concrete here, just some vague statement that newer versions are supposedly unusable despite many many people using them daily and it seems to somehow work for them. |
Honestly, it's quite tiring because you can figure this out on your own by just going into https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc and type "Nix 2.3", obvious results will appear. We spent the last years explaining and answering to this over and over, this is disrespectful of the time of others. What has been said for the last years was: "If you don't want Nix 2.3 to be removed, get zstd support", this is now done. If you have objective and valid reasons to remove Nix 2.3, I am interested, for the time being, I do not see them, therefore, there's no reason to drop support for Nix 2.3 at the moment. The project is frustrating enough for a lot of folks which were disrespected and burned out in the past, let's not make them ragequit just for the sake of increasing a version number with no benefits. If you want Nix 2.3 to move, please, let's collect all reasonable Nix 2.3 regressions, show they are fixed in a Nix release that is supported by nixpkgs and we can potentially move the needle there. In the meantime, thanks to @edef1c efforts, Nix 2.3 community did the work to unblock people wanting zstd support. This cannot work only in one way. |
|
With nix 2.3 having gained zstd support this PR has been made obsolete for my cause. Please make sure these patches make it into nixpkgs. |
|
Tracked in NixOS/nix#9244. |
Nix 2.3 is the last version not using libarchive for decompression and
therefore prevents us from migrating the compression algorithm used for
the binary cache.
This resulted from interest in using zstd compression on hydra.
Description of changes
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes