| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
the term was hard to discover, as its definition and explanation were in
a very long document lacking an overview section.
search did not help because it occurs so often.
- clarify wording in the definition
- add an overview of installable types
- add "installable" to glossary
- link to definition from occurrences of the term
- be more precise about where store derivation outputs are processed
- installable Nix expressions must evaluate to a derivation
Co-authored-by: Adam Joseph <54836058+amjoseph-nixpkgs@users.noreply.github.com>
|
|
this is easier to edit, provides anchors for free, and renders correctly
on the terminal without additional effort.
|
|
|
|
|
|
Fixes #7939.
|
|
bobvanderlinden/pr-improve-nix-profile-install-error
Improve error on conflict for nix profile install
|
|
|
|
Whenever a file conflict happens during "nix profile install" an error
is shown that was previously thrown inside builtins.buildEnv.
We catch BuildProfileConflictError here so that we can provide the user
with more useful instructions on what to do next.
Most notably, we give the user concrete commands to use with all
parameters already filled in. This avoids the need for the user to look
up these commands in manual pages.
|
|
Make `--read-only` a separate mixin
|
|
Move Derivation JSON printing logic to lib and test it
|
|
It is independent of SourceExprCommand, which is about parsing
installables, except for the fact that parsing installables is one of
the many things influenced by read-only mode.
|
|
The REPL itself and the `nix repl` CLI are conceptually different
things, and thus deserve to be in different files.
|
|
|
|
|
|
Factor out `InstallableStorePath` to its own file, dedup
|
|
This is a bit more accurate.
It's a private name, but before you know it, someone might make it public!
|
|
Per the old FIXME, this flag was on too many commands, and mostly
ignored. Now it is just on the commands where it actually has an effect.
Per https://github.com/NixOS/nix/issues/7261, I would still like to get
rid of it entirely, but that is a separate project. This change should
be good with or without doing that.
|
|
`nix app` had something called `InstallableDerivedPath` which is
actually the same thing. We go with the later's name because it has
become more correct.
I originally did this change (more hurriedly) as part of #6225 --- a
mini store-only Nix and a full Nix need to share this code. In the first
RFC meeting for https://github.com/NixOS/rfcs/pull/134 we discussed how
some splitting of the massive `installables.cc` could begin prior, as
that is a good thing anyways. (@edolstra's words, not mine!) This would
be one such PR.
|
|
Move `trustedUsers` and `allowedUsers` to separate config struct
|
|
These settings are not needed for libstore at all, they are just used by
the nix daemon *command* for authorization on unix domain sockets. My
moving them to a new configuration struct just in that file, we avoid
them leaking anywhere else.
Also, it is good to break up the mammoth `Settings` struct in general.
Issue #5638 tracks this.
The message is not changed because I do not want to regress in
convenience to the user. Just saying "this connection is not trusted"
doesn't tell them out to fix the issue. The ideal thing to do would be
to somehow parameterize `processCommand` on how the error should be
displayed, so different sorts of connections can display different
information to the user based on how authentication is performed for the
connection in question. This, however, is a good bit more work, so it is
left for the future.
This came up with me thinking about the tcp:// store (#5265). The larger
project is not TCP *per se*, but the idea that it should be possible for
something else to manage access control to services like the Nix Daemon,
and those services simply trust or trust the incoming connection as they
are told. This is a more capability-oriented way of thinking about trust
than "every server implements its own auth separately" as we are used to today.
Its very great that libstore itself already implements just this model,
and so via this refactor I basically want to "enshrine" that so it
continues to be the case.
|
|
This is (morally) dead code.
As @edolstra pointed out in
https://github.com/NixOS/nix/pull/5226#discussion_r1073470813, this is
no longer needed.
I created this in 8d4162ff9e940ea9e2f97b07f3030a722695901a, so it is
fitting that I now destroy it :).
|
|
nix store ping: add --json flag
|
|
Better error message for nix search when attr is not found
|
|
For frameworks it's important that structures are as lazy as possible
to prevent infinite recursions, performance issues and errors that
aren't related to the thing to evaluate. As a consequence, they have
to emit more attributes than strictly (sic) necessary.
However, these attributes with empty values are not useful to the user
so we omit them.
|
|
|
|
|
|
No other getDefaultFlakeAttrPaths implementation has this trailing dot,
and the dot can show up in error messages like:
error: flake '...' does not provide attribute 'packages.x86_64-linux.', ...
|
|
Avoid needless work and throwing away invariants.
These conversions date back to when `StorePath` was in Rust and there
were issues with it missing utility methods.
|
|
Move the default profiles to the user’s home
|
|
|
|
|
|
nix/show-config: allow getting the value of a specific setting
|
|
This reverts commit 9b33ef3879a764bed4cc2404a08344c3a697a646.
|
|
This reverts commit a75b7ba30f1e4f8b15e810fd18e63ee9552e0815, reversing
changes made to 9af16c5f742300e831a2cc400e43df1e22f87f31.
|
|
Rather than using `/nix/var/nix/{profiles,gcroots}/per-user/`, put the user
profiles and gcroots under `$XDG_DATA_DIR/nix/{profiles,gcroots}`.
This means that the daemon no longer needs to manage these paths itself
(they are fully handled client-side). In particular, it doesn’t have to
`chown` them anymore (removing one need for root).
This does change the layout of the gc-roots created by nix-env, and is
likely to break some stuff, so I’m not sure how to properly handle that.
|
|
This avoids warning fatigue, making `nix flake check` more effective.
|
|
Instead of needing to run `nix show-config --json | jq -r
'."warn-dirty".value'` to view the value of `warn-dirty`, you can now
run `nix show-config warn-dirty`.
|
|
This forces us to be explicit.
It also requires to rework how `from_json` works. A `JSON_IMPL` is added
to assist with this.
|
|
`DerivedPath::Built` and `DerivationGoal` were previously using a
regular set with the convention that the empty set means all outputs.
But it is easy to forget about this rule when processing those sets.
Using `OutputSpec` forces us to get it right.
|
|
Do this prior to making a new more limitted `OutputPath` we will use in
more places.
|
|
A few little changes preparing for the rest.
|
|
Prior to this change, we had a bunch of ad-hoc string manipulation code
scattered around. This made it hard to figure out what data model for
string contexts is.
Now, we still store string contexts most of the time as encoded strings
--- I was wary of the performance implications of changing that --- but
whenever we parse them we do so only through the
`NixStringContextElem::parse` method, which handles all cases. This
creates a data type that is very similar to `DerivedPath` but:
- Represents the funky `=<drvpath>` case as properly distinct from the
others.
- Only encodes a single output, no wildcards and no set, for the
"built" case.
(I would like to deprecate `=<path>`, after which we are in spitting
distance of `DerivedPath` and could maybe get away with fewer types, but
that is another topic for another day.)
|
|
- Add a comment
- Put `OutputsSpec` in a different header (First part of #6815)
- Make a few stray uses of it in new code use `DerivedPath` instead.
|
|
|
|
|
|
|
|
NixOS modules can be paths. Rather than dig further down into the layer
violation, don't check anything specific to NixOS modules.
|
|
Fix `nix why-depends --derivation`
|
