Skip to content
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

Updated flake documentation #2917

Merged
merged 1 commit into from Jun 18, 2019
Merged

Updated flake documentation #2917

merged 1 commit into from Jun 18, 2019

Conversation

CSVdB
Copy link
Contributor

@CSVdB CSVdB commented Jun 3, 2019

No description provided.

@edolstra edolstra added the flakes label Jun 7, 2019
@@ -164,14 +155,17 @@ Similarly, a minimal `flake.nix` for Nixpkgs:
{
name = "nixpkgs";

epoch = 201906;
epoch = 2019;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be changed?

@@ -2,92 +2,80 @@

## Goals

* To provide Nix repositories with an easy and standard way to
reference other Nix repositories.
* Standard and easy dependency handling in Nix
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ambiguous because it doesn't explain what is meant with dependency handling. I mean, Nix has always done "dependency handling" between packages, it just didn't have dependency handling for Nix repos.


* To allow such references to be queried and updated automatically.
* Discoverability: Be able to query and update dependencies automatically
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idem: this suggests we're querying/updating package dependencies (like the many auto-updates that exist for Nixpkgs).


* To enable reproducible, hermetic evaluation of packages and NixOS
configurations.
* Reproducibility: Evaluate packages and NixOS configurations purely by default
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Hermetic" is arguably a more fashionable term.

* Flakes *provide* an attribute set of values, such as packages,
Nixpkgs overlays, NixOS modules, library functions, Hydra jobs,
`nix-shell` definitions, etc.
* A flake *provides* an attribute set of values, such as packages, Nixpkgs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be "A flake outputs"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree. I think "to provide" is much clearer. I don't understand what a flake "outputs" would really look like.

command. That is, commands such as `nix install` ignore all other
flake attributes.
* `packages`: A set of installable derivations used by the `nix` command. That
is, commands such as `nix install` ignore all other flake attributes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should mention that packages cannot be a nested set.


* `commitHash` (or `rev`?) (not for tarball flakes): The Git commit
hash.
* `devShell`: A specification of a development environment in some TBD format.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The format is that it's just a regular derivation.

* Add a flake attribute to specifiy non-flake dependencies, e.g.

> nonFlakeInputs.foobar = github:foo/bar;
* `self`: The path to the flake's source code
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in fact the result of the flake's output which is passed into itself. So self.outputs.foo should work.

direnv.
where `builtins.flakeRegistry` is the global registry with user overrides
applied, and `builtins.getFlake` downloads a flake and resolves its
dependencies.


## Pure evaluation and caching

Flake evaluation should be done in pure mode. Thus:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be done -> is done.

* Download a precomputed cache
(e.g. `https://releases.nixos.org/eval/<flake-closure-hash>.sqlite`). So
a command like `nix search` could avoid evaluating Nixpkgs entirely.
* Keep a local evaluation cache (say `~/.cache/nix/eval.sqlite`) mapping
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is concretly ~/.cache/nix/eval-cache-v1.sqlite now.

@CSVdB CSVdB force-pushed the docs branch 2 times, most recently from e0a1aed to 552b2f4 Compare June 18, 2019 08:21
@edolstra edolstra merged commit d4a48b1 into NixOS:flakes Jun 18, 2019
@CSVdB CSVdB deleted the docs branch June 18, 2019 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants