The goal is to reduce the flake inputs visible to the user
Still, the top-level flake re-exposes the outputs of the dev-flake, but
without exposing its inputs. This means a devShell is still available in
the top-level, for example.
This also removes the /modules/flake.nix. Its original purpose was
separating the modules inputs from the development inputs, but this is
now done the opposite way around by moving the dev inputs to
/dev-flake/flake.nix.
The pip locker [sometimes created a URL without hash][1] to reflect that there was a local source.
This produced the following error when trying to evaluate that derivation:
… from call site
at /nix/store/qdzdi6qvrqxfqxhi3j70d5dsl9f5jpby-source/modules/dream2nix/pip/default.nix:86:28:
85| mkDerivation = {
86| src = l.mkDefault (fetchers.${metadata.sources.${config.name}.type} metadata.sources.${config.name});
| ^
87| doCheck = l.mkDefault false;
… while calling 'url'
at /nix/store/qdzdi6qvrqxfqxhi3j70d5dsl9f5jpby-source/modules/dream2nix/pip/default.nix:57:11:
56| fetchers = {
57| url = info: l.fetchurl {inherit (info) url sha256;};
| ^
58| git = info: config.deps.fetchgit {inherit (info) url sha256 rev;};
error: value is null while a string was expected
Of course, one cannot call `builtins.fetchurl` without a `sha256` argument.
Now, local dependencies are specified exactly like that in the lock file. Now, we'll fetch nothing when dealing with local dependencies.
Also, their evaluation when generating `preFixup` attribute is delayed until build time. This was a bigger problem due to the previous bug, but in any case it should still help to reduce evaluation overhead.
FWIW, sometimes local sources might not really exit in the derivation source tree until build time. For example, when building aggregated sources with meta-repo management tools such as Mr. Chef.
[1]: 40b65e4598/pkgs/fetchPipMetadata/src/fetch_pip_metadata/lock_file_from_report.py (L72C28-L72C28)
For many users not having a snapshot date is a valid use case.
Also many users will expect their lock file to be updated to the latest dependency versions via a nix run .#package.config.lock.refresh. so it can be the default behavior.
- nixpkgs-overrides are not lazy enough. They can lead to eval failures thrown in nixpkgs despite not being enabled. Therefore we better use the `import` as an enable mechanism instead of the `enable` option.
We keep the enable option to allow for users to disable the override module via mkForce
