Otherwise references to the Python interpreter inside the set are wrong, as demonstrated by:
``` nix
with import <nixpkgs> { };
let
python' = python3.override {
packageOverrides = final: prev: { requests = prev.requests.overridePythonAttrs(old: { version = "1337"; }); };
};
in python'.pkgs.python.pkgs.requests
```
which returns the _non_ overriden requests.
And the same with `self`:
```
with import <nixpkgs> { };
let
python' = python3.override {
self = python';
packageOverrides = final: prev: { requests = prev.requests.overridePythonAttrs(old: { version = "1337"; }); };
};
in python'.pkgs.python.pkgs.requests
```
which returns the overriden requests.
This can manifest itself as file collisions when constructing environments or as subtly incorrect dependency graphs.
This adds `--disable-macos-fs-link` to configureFlags on darwin
platforms, removing /etc/fstab and `mount -t bindfs` support.
This isn't ideal, but is better than the tool not building at all.
Since theey is not active from at least six years.
All the packages on this commit became orphans.
---------------------------------------------------------------------------
There are files not covered by this commit, because they will be adopted
soon. Namely:
- pkgs/by-name/zs/zsync/package.nix
- pkgs/games/bsdgames/default.nix
- pkgs/misc/ghostscript/default.nix
- pkgs/os-specific/linux/kernel/perf/default.nix
- pkgs/tools/system/logrotate/default.nix
* nickel: switch to cargoHash
* gnvim-unwrapped: switch to cargoHash
* surrealdb-migrations: switch to cargoHash
* wluma: switch to cargoHash
* httm: switch to cargoHash
No need (observed) for these packages to have a vendor Cargo.lock. If they for some reason have to use a different Cargo.lock than upstream, they should copy that to the build directory as well, otherwise the build will fail. They don't, so I infer there's no reason to use Cargo.lock.
This makes sure the correct Python version is detected by using the local m4 files.
The distributed m4 files were added in
ff043af128
to make sure the Python version is detected correctly,
but now fail to identify versions > 3.9 correctly (https://bugs.gnu.org/44239).
fix#325079
