-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Auto-generate store documentation #8084
Conversation
This command was intended for docs generation, but it was never used for that and we don't need it.
Why not 'nix help stores'? Well, 'nix help <arg>' already means 'show help on the "arg" subcommand'.
This makes the help commands show up prominently at the top of the 'nix' manpage.
Since setting names are not unique we don't have an easy way to produce unique anchors.
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 can't follow why this is a separate command, while all it does is render documentation. I saw somewhere nix store --help
being mentioned in reference to that, but can't find the source. I think that information should simply be on the front page of nix store --help
instead.
For example, the following uses `/tmp/root` as the chroot environment | ||
to build or download `nixpkgs#hello` and then execute it: | ||
|
||
```console | ||
# nix run --store /tmp/root nixpkgs#hello | ||
Hello, world! | ||
``` |
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 think we should make a definitive decision on whether and how to document experimental features in the stable parts of the manual. Similar situation in the hacking guide.
While this, for now, will only show in nix
command docs, there is no reason not to have it everywhere it matters, since that stuff is already stable.
@@ -0,0 +1,40 @@ | |||
R"( | |||
|
|||
**Store URL format**: `local`, *root* |
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 had to read multiple examples to understand that this notation means an enumeration of store formats. There probably is a better way to express this in a way that is immediately clear, but I don't see one yet.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
That's what this PR originally did, but I think having a |
Discussed in the Nix team meeting 2023-03-23:
|
I'd like to re-iterate that currently our paradigm to view parts of the manual on the command line is |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-03-23-nix-team-meeting-minutes-43/26758/1 |
Just to be clear: the conclusion was that it makes sense to make the store documentation available in the manual in some other location than under |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/this-month-in-nix-docs-1-march-2023/26913/1 |
Motivation
This makes information about the supported store types and their settings in
nix help-stores
. Store types can now also have some "global" Markdown documentation.This PR also removes
nix describe-stores
since we don't actually need it for docs generation and it doesn't really have any other use cases. (If really needed the JSON is still available in the internalnix __dump-cli
command.)Closes #5467. Fixes #6279.
Context
Checklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.sh
src/*/tests
tests/nixos/*
Priorities
Add 👍 to pull requests you find important.