When resolving indirect flake references like `nixpkgs` in `flake.nix`
files, Nix will no longer use the system and user flake registries. It
will only use the global flake registry and overrides given on the
command line via `--override-flake`.
Commit cfe66dbec updated `nix upgrade-nix` to use
`ExecutablePath::load().find`, which broke the logic for finding the
profile associated with the nix executable. The error looks something
like:
```
$ sudo -i nix upgrade-nix --debug
found Nix in '"/nix/store/46p1z0w9ad605kky62dr53z4h24k2a5r-nix-2.25.2/bin/nix"'
found profile '/nix/store/46p1z0w9ad605kky62dr53z4h24k2a5r-nix-2.25.2/bin'
error: directory '"/nix/store/46p1z0w9ad605kky62dr53z4h24k2a5r-nix-2.25.2/bin/nix"' does not appear to be part of a Nix profile
```
This seems to happen for two reasons:
1. The original PATH search resulted in a directory, but `find` returns
the path to the executable. Fixed by getting the path's parent.
2. The profile symlink cannot be found because
`ExecutablePath::load().find` canonicalizes the executable path. I
updated find to normalize the path instead, which seems more in line
with how other programs resolve paths. I'm not sure if this affects
other callers though.
I manually tested this on macOS and Linux, and it seemed to fix
upgrading from 2.25.2 to 2.25.3.
Fix a footgun. In my case, I had a couple of build ("output")
directories sitting around.
rm -rf build-*
Was confused for a bit why a meson.build file was missing.
Probably also helps with autocompletion.
I tried meson-build-support first, but I had to add something like
a nix- prefix, in order to make meson happy. They've reserved the
meson- prefix.
Before this change, expressions like:
with import <nixpkgs> {};
runCommand "foo" {} ''
echo '@nix {}' >&$NIX_LOG_FD
''
would result in Lix crashing, because accessing nonexistent fields of
a JSON object throws an exception.
Rather than handling each field individually, we just catch JSON
exceptions wholesale. Since these log messages are an unusual
circumstance, log a warning when this happens.
Fixes#544.
Change-Id: Idc2d8acf6e37046b3ec212f42e29269163dca893
(cherry picked from commit e55cd3beea710db727fd966f265a1b715b7285f3)
Instead of the unhelpful
warning: 'https://cache.flakehub.com' does not appear to be a binary cache
you now get
warning: unable to download 'https://cache.flakehub.com/nix-cache-info': HTTP error 401
response body:
{"code":401,"error":"Unauthorized","message":"Unauthorized."}
Upstream `bzip2` does not provide `pkg-config` files. As a result an
attempt to build `nix` on some distributions like Gentoo failos the
configure as:
$ meson setup ..
...
Executing subproject perl
...
perl| Run-time dependency bzip2 found: NO (tried pkgconfig and cmake)
../src/perl/meson.build:68:12: ERROR: Dependency "bzip2" not found, tried pkgconfig and cmake
The change falls back to `bz2` library for such cases.
This prevents any potential cases of deletion through base pointer and its
non-virtual dtor, which might leak memory. Also gets rid of the warning:
/nix/store/fg7ass3a5m5pgl26qzfdniicbwbgzccy-gcc-13.2.0/include/c++/13.2.0/bits/stl_construct.h:88:2: warning: destructor called on non-final 'nix::flake::Settings' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor]
88 | __location->~_Tp();
....
../src/libflake-c/nix_api_flake.cc:10:30: note: in instantiation of function template specialization 'nix::make_ref<nix::flake::Settings>' requested here
10 | auto settings = nix::make_ref<nix::flake::Settings>();
This gets rid of unnecessary copies in range-based-for loops and
local variables, when they are used solely as `const &`.
Also added a fixme comment about a suspicious move out of const,
which might not be intended.
