It was mentioned by me at the beginning of this thread But I argue the exact opposite. Deprecate the with
syntax for let inherit
as it’s obviously superior
(Several posts talk about deprecating with
in favor of let
, but the point was that warbo has precisely the antipodal argument?)
- Getting PHP-FPM to work with nginx - a pretty common setup - involves unnecessarily much work. Much of this could be abstracted away by a module configuration option.
- Copy-pastability of configuration examples is low, which can make it challenging to understand how to configure something correctly without making a mess of your existing configuration - because the same configuration can be represented in many ways and often examples are dependent on context and abstractions that live in other people’s repositories. Nix flakes would probably alleviate this a lot, by reducing the need to copy-paste examples, instead lowering the bar for publishing and consuming third-party abstractions/presets.
When you do this:
pkgs.stdenv.mkDerivation {
name = "foo";
src = ./some/folder;
installPhase = ''
cp -r $src/ $out/
cp ${../elsewhere/extra-file.txt} $out/extra-file.txt
'';
}
… the copying of extra-file.txt
will fail with a cryptic permission error. This occurs because the permissions from the source directory (which is read-only, being in the Nix store) are copied over to the new $out
directory that is implicitly being created, which prevents any later copying of files into it.
You need to explicitly mkdir -p $out
first, instead, to create the folder with the default permissions, so that the cp
after it merely copies over the contents:
pkgs.stdenv.mkDerivation {
name = "foo";
src = ./some/folder;
installPhase = ''
mkdir -p $out/
cp -r $src/ $out/
cp ${../elsewhere/extra-file.txt} $out/extra-file.txt
'';
}
No idea how this could be made more usable (on an implementation level), but I’d imagine that it might be a pretty common thing to forget a mkdir
. There should probably be at least a warning of some sort.
When package sets are written like gitAndTools
:
/* All git-relates tools live here, in a separate attribute set so that users
* can get a fast overview over what's available.
*/
args @ {config, lib, pkgs}: with args; with pkgs;
let
gitBase = callPackage ./git { ... };
self = rec {
git = appendToName "minimal" gitBase;
gitFull = gitBase.override { ... };
};
in
self
…it becomes really annoying to try and override the definition of gitBase
or whatever local bindings are defined, because you have to do so for every attribute in the set that uses the binding; and there’s really no reason not to expose the binding so it can be overridden. It doesn’t reduce closure sizes, and we’re already in a scope so it’s not polluting the top level.
In general, I wish for a convention that any binding made with callPackage
should be exposed to the top level of the scope in which it’s used. emacs-packages.nix
is an egregious offender.
I’m not sure if I’m your reading your point correctly, but fundamentally I agree and I’m massively annoyed by these kinds of problems.
(WIP)(RFC) A new nixpkgs frontend for language infrastructures - #2 by deliciouslytyped is intended to address this kind of structure.
However, a much simpler thing to do at least in this case - if a simple rec set is acceptable - is to make the self
attr take an argument and pass gitBase
as a parameter - if I’m following correctly.
I see two issues here; one is that let expressions are horrible for overridability, the other is whether what is consuming your inputs is parametrized over it’s scope (bad for overriding), or over explicit arguments (good for overriding). I use “horrible” to emphasize my strong feelings towards this, but I’m always open to being convinced otherwise.
Hey, I have a paper cut.
nix-env
without absolute paths is unbearably slow.
In my experience, nix-env -i foo
is much slower than even nix search foo && nix-env -iA nixos.foo
In my experience,
nix-env -i foo
is much slower than evennix search foo && nix-env -iA nixos.foo
Doesn’t nix search
cache something? I guess nix-env -i
is unlikely to ever become fast enough again…
Doesn’t
nix search
cache something? I guessnix-env -i
is unlikely to ever become fast enough again…
If that’s the case (i.e. nix-env
not caching), then why are absolute paths (e.g. nixos.git
) so fast?
Either way, could nix-env
not try the prefix nixos
etc first before doing an uncached search for possible absolute paths?
I’m sure there’s a reason. I’m just not seeing it :-/
If that’s the case (i.e.
nix-env
not caching), then why are absolute paths (e.g.nixos.git
) so fast?Either way, could
nix-env
not try the prefixnixos
etc first before doing an uncached search for possible absolute paths?
nix-env -i
evaluates all packages to find all packages with the specified name and then choose by priority and version. Heuristics allowing to find some of the packages with the chosen name quickly are not enough there.
nix-env -iA
uses lazy evaluation etc. to evaluate only the part of Nixpkgs that is necessary for the single package specified via attribute path. It doesn’t have any reason to check if, say, tig
has name “git” and higher version than git
(the definition of nix-env -i
implies doing this check and many many similar ones).
What we really should do is ship a database of package names with each channel to speed up nix-env -i
. If you stick a nixpkgs checkout in your NIX_PATH
that wouldn’t help, but as long as you’re using channels, there’s no reason nix-env
really should be evaluating the entire package set each time.
Of course, it would still need to evaluate overlays, but I’m sure we can do some magic where we intercept overlays, evaluate just those, and ignore the overridden paths from the database.
The idea was to stop using nix-env -i
altogether. Except we don’t have a replacement yet. Right now the best option is to find the attribute with nix search
and then use nix-env -iA
.
Related to that there is also the programs.sqlite
DB that is generated for the nixos channels. This DB is currently only used by the command-not-found
program. The schema looks like this:
It would be nice to also generate that DB for the other channels so command-not-found and other tools can be built on top.
The confusion around overlapping phase variable/functions in nix-shell.
The explanation was quite hard to find:
https://github.com/NixOS/nix/issues/456
Only reason I bothered fighting through finding this is because a newbie asked the very sane question “but then how do I test my phases…”
I’m not proud of the fact that I’ve been copy-pasting phases out of nix show-derivation
.
I sometimes get annoyed by the way derivations are named. Right now I’m looking for programs to manage my photo collection and I’ve found a list online that I’m trying. Of course I use nix-shell, so I enter…
$ nix-shell -p digik<tabtab>
digikam digikam5
meh… are these the same? is “digikam” version 4 or version 6? I don’t want to dig into nixpkgs to figure that out, I just want the most recent packaged version.
Use nix search digikam
to find the attribute name. Then, use the attribute name with nix run
, e.g. nix run nixpkgs.digikam
. Don’t use nix-shell -p
, it’s not meant for what you’re doing.
nix run has the same problem, when I don’t want to run a search:
$ nix run nixpkgs.digikam<tabtab>
nixpkgs.digikam nixpkgs.digikam5
Having to run a search just because the attribute names are unclear is what I consider to be the papercut here.
Not completely ideal, but you can quickly find out the versions with nix-eval
as well:
~ % nix eval nixpkgs.digikam.version
"6.2.0"
~ % nix eval nixpkgs.digikam5.version
"6.2.0"
I know that there are severall ways to figure that out. My point is that it’s not obvious from the name of the attribute.
I did a talk at nixcon called nix at home last year that briefly covered how to use nix on non-nixos to generate systemd services. An Introduction to Nix for Developers
Any chance you could turn this into a nixos.wiki page?
I’ve been wondering if this was possible for a while now and it’d be nice to have a simple intro page for it