-
-
Notifications
You must be signed in to change notification settings - Fork 312
dynamically generate Nix manual version overview #863
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dynamically generate Nix manual version overview #863
Conversation
cfc2652 to
8a71272
Compare
|
I looked at the changes and they seem ok, I don't know what you were referring to when you said "whether to generate pages at all" (what's the alternative? Not have any links to the nix manuals from nix.dev?). However, I've been thinking. Is it possible to grab the nix version directly from each channel during CI? By that I mean, can we do a few "niv add " in CI and then for each channel, run |
infinisil
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked at the changes and they seem ok, I don't know what you were referring to when you said "whether to generate pages at all" (what's the alternative? Not have any links to the nix manuals from nix.dev?).
Emphasis is on generate. The alternative would be to not merge this PR, which then requires manually updating the Nix versions in the .md file whenever stable/unstable changes.
I think it's good to have this, automation is key!
fe6f02f to
3d5d896
Compare
infinisil
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh just noticed a problem with this: If we update Nix versions, we'd be invalidating old version-specific links like https://nix.dev/manual/nix/2.18/.... So we should never do minor version updates for niv entries, but rather add new ones.
|
We could also link to |
3d5d896 to
2d56125
Compare
b6c585f to
926f8fa
Compare
CONTRIBUTING.md
Outdated
| - On each new Nix release, update the `nix-latest` to the corresponding release branch: | ||
|
|
||
| 1. Add the latest version in [`default.nix`](./default.nix). | ||
| For example, to add Nix 2.19: | ||
|
|
||
| ```bash | ||
| niv add nixos/nix -n nix_2-19 -b 2.19-maintenance | ||
| ``` | ||
|
|
||
| 2. Reference the latest version in [`source/reference/nix-manual.md`](./source/reference/nix-manual.md). | ||
| ```bash | ||
| niv update nix-latest -b 2.20-maintenance | ||
| ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My above previous concern is still valid: This would break version-specific links, that's a no-go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid #863 (comment) wasn't a good suggestion after all
f165e98 to
098b8dd
Compare
- refactor `default.nix` for hopefully better readability - de-noise the overview page text
before that, the script was semantically wrong as it pinned to the tip of the branch.
this will accumulate releases over time. it's not great, but this is the
price of persistent URLs. otherwise, when people link to supposedly stable
URLs, and we garbage-collect old manuals, those links will rot away.
it's also slightly simpler algorithmically, and therefore easier to
reason about.
this can be incrementally improved in the future, by automatically
adding redirects to e.g. the closest following release for which the
manual is still served. for example, if we currently serve
23.11
23.05
22.11
22.05
but in the future decide to cut that list to the first two, the script
would drop the excess pins and add redirects like these:
/manual/nixpkgs/22.05/* /manual/nixpkgs/23.05/:splat 301
/manual/nixpkgs/22.11/* /manual/nixpkgs/23.05/:splat 301
the condition for that would be that we are reasonably sure that the
manuals will manage their own internal redirects as pages and anchors
move around between releases.
098b8dd to
98bae7c
Compare
98bae7c to
e837576
Compare
- Use separate JSON files to track sources for Nixpkgs and Nix releases This greatly simplifies the code, because we can directly encode versions as keys without ambiguity - Avoid an instance of IFD for the redirect generation - Use pkgs.substitute instead of builtins.replaceStrings - Turn off the single-page feature for now. It was added by Valentin in a previous commit, but I think we should discuss this a bit more - Simplify a lot of the code and add comments - Fix the mutable redirects, they were broken by a parent commit - Remove pieces of Nix code that weren't used, like the import of the Nixpkgs manual. This can be added in the future when necessary - Make sure that Nix versions are cached by building from the store path
4daecbe to
f479463
Compare
|
I'm afraid the code felt very cobbled together overall.. I kind of refactored the entire code now 😅. Please check the commit message for more details, but this PR looks good to me now. I tested it locally with
I reverted that for now, though I left it in the code: Lines 54 to 56 in 4daecbe
This feels way too hacky for me, it should be discussed a bit more. And there's no reason this has to be part of this PR, let's not make it bigger than it already is! |
|
@infinisil thanks a lot for the review pass, it's quite solid now. I'll open a new PR for single-page rendering. |
infinisil
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops fat fingers, though it looks like auto-merge doesn't do much when somebody still requested changes, I guess I'll have to approve :)
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tweag-nix-dev-update-56/43035/1 |

this removes more manuals steps from adapting the site to new releases.
@nixos/documentation-team please bikeshed whether to generate pages at all, as this introduces some mental overhead for working with the site.
depends on #830