nix: put each version in a separate file #211172
Conversation
ofborg
bot
added
10.rebuild-darwin: 1-10
10.rebuild-darwin: 1
10.rebuild-linux: 1-10
labels
|
Please do not squash the commits; there is important (reconstructed) history in there. |
|
@grahamc the darwin builders are wedged again |
|
@ofborg eval |
ofborg
bot
added
10.rebuild-darwin: 0
10.rebuild-linux: 0
and removed
10.rebuild-darwin: 1
10.rebuild-darwin: 1-10
10.rebuild-linux: 1-10
labels
It doesn't. OfBorg shows zero rebuilds. |
ghost
marked this pull request as draft
ghost
marked this pull request as ready for review
I was looking at the commit history which shows some reverts and back and forth https://github.com/NixOS/nixpkgs/pull/211172/commits |
None of them remain reverted by the end of the PR. Check the net effect of the entire patch series. |
|
Resolved (non-hypothetical) merge conflict (this is the churn I'm talking about). |
ghost
mentioned this pull request
Done. Note: rebasing this PR is extremely labor-intensive. |
ghost
marked this pull request as draft
ghost
marked this pull request as ready for review
ghost
requested review from
Artturin and
SuperSandro2000
and removed request for
SuperSandro2000 and
Artturin
I am doing that myself here https://github.com/supersandro2000/nixpkgs/tree/nixos-22.11 with 120 commits on top of stable and rebasing it usually twice or more a week and do not have such problems. I am using the following commands to rebase: So from my perspective this change is not necessary. Also if we are going to merge this, can we just squash the history together? Having those 2 revert commits makes the history a bit messy. |
Because you're rebasing against the slow-moving I "live at head" and run I know that not everybody can do this, but if nobody did it we wouldn't find out about most bugs until ZHF. I also build everything myself ( |
I've squashed it into only three commits:
The reason for this is so that people who want the old versions back can I suppose the first two commits could be fused together. I think it conveys useful information about what happened here. I've rewritten the commit message so it doesn't "look like" an obvious revert (see fc8b055) since I mean no offense toward the people who wrote the commit that I am reverting. If you still feel strongly about reducing the number of commits I can squash the first two commits together. Squashing all three would make it obnoxiously difficult for people to bring back the deleted versions; I don't think that's a good idea. |
ofborg
bot
added
10.rebuild-darwin: 101-500
10.rebuild-linux: 101-500
and removed
10.rebuild-darwin: 0
10.rebuild-linux: 0
labels
I am doing the same with nixos-unstable and also run into very little problems.
Feel free to do that but I would highly recommended against directly tracking master and instead suggest to anyone to use nixos-unstable.
This will probably only ever be useful for a handful of people while way more people need to live with the messy history and wrap their head around the back and forth in the history. A PR that first introduces code that is later deleted in the same PR has a messy history. We should avoid that if it is easily possible which it is here. You can do whatever change you like on your fork but we should keep the history try to keep the history clean especially if it is easily done. |
I laughed at this. The nixpkgs history is a complete rat's nest already. Squashing two commits together isn't going to fix that. I don't think anybody sits down and reads the whole thing from start to finish. |
|
I would also like to point out that when we carry multiple versions of a package it is nixpkgs convention to put each one in a separate file. Currently |
lib/filesystem.nix
Outdated
| /* | ||
| Given a directory and a regex, return a list of basenames of | ||
| files in that directory which match the regex. | ||
| */ | ||
| listFilesMatching = regex: dir: | ||
| lib.lists.filter (x: x!=null) | ||
| (lib.mapAttrsToList | ||
| (k: _: if builtins.match regex k == null then null else k) | ||
| (builtins.readDir dir)); |
There was a problem hiding this comment.
I'm not sure if this is a good function to introduce into lib. I think it would be cleaner to have a pkgs/tools/package-management/nix/versions directory where each entry corresponds to a version, then you don't need a regex filter and can just use readDir. Same for other packages if necessary.
There was a problem hiding this comment.
I think it would be cleaner to have a
pkgs/tools/package-management/nix/versionsdirectory where each entry corresponds to a version, then you don't need a regex filter and can just usereadDir
I agree. Done: e618baa.
The original naming scheme came from this request.
I will update all of this to match RFC140 when it is finished and implemented. However between now and then, having pkgs/tools/package-management/nix/ package split up into file-per-version will save rebasing pain on every commit that touches this directory.
I assume RFC140's implementation will include something like (and more general than) the three version_to_ helper functions, so those will go away.
|
Rebased again. |
ofborg
bot
added
10.rebuild-darwin: 1-10
10.rebuild-linux: 1-10
and removed
10.rebuild-darwin: 101-500
10.rebuild-linux: 101-500
labels
This commit temporarily restores nixVersions 2.4-2.9 so the following commit can split them into separate files before re-performing the deletion (against the kept-in-separate-files version).
Some of us need to keep around specific versions of nix. The recent churn of which Nix versions are or are not in nixpkgs is causing a lot of merge conflicts for us. Let's put each version in a separate file, so these churn commits aren't constantly conflicting with nearby lines of code.
|
Rebased. |
1 similar comment
|
Rebased. |
There was a problem hiding this comment.
I agree with the overall change here, but I don't agree with this:
I've squashed it into only three commits:
1. Revert the deletion 2. Move into separate files 3. Re-do the deletionThe reason for this is so that people who want the old versions back can
git revertthe last commit (and carry that revert forward in their local tree). So it is really valuable to have that change isolated as a single commit -- it makes it straightforward for people to re-enable the no-longer-supported versions.
There is no CI checking that these packages actually work in even those 2 commits. And making it easier to get back these deleted versions encourages people to still use them, maybe submit fixes to them. It also sets a precedent, encouraging others to also add commits like these to other PRs.
We should either actively support packages if they're still needed, or not support them at all imo.
There is no CI checking a lot of things, unfortunately. |
Description of changes
Some of us need to keep around specific versions of nix.
The recent churn of which Nix versions are or are not in nixpkgs is causing a lot of merge conflicts for us.
Let's put each version in a separate file, so these churn commits aren't constantly conflicting with nearby lines of code.
Things done