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.
...not pythonPackage. This is an app, living in pkgs/servers, so
we just use callPackage in all-packages and drop the python module.
python3.pkgs.toPythonModule could be used if a python module was needed.
Before that change legacyPackages.x86_64-linux.python311.pkgs.etebase-server.python
would give a python 3.12 release, and was therefore broken.
etebase-server = toPythonModule (pkgs.etebase-server.override {
python3 = python;
});
would now be correct
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
...version. Upstream still uses pydantic 1, which it
implicitly imports via fastapi. Overriding that and its
pydantic-using dependencies fixes it, until upstream updates.
For some reason the pyproject build setp started to fail. Since the
pyproject.toml is basically empty I'm switching this project to the
format "other".
