The hook performs a depth first search on the graph defined by
propagatedBuildInputs. This traverses all paths through the graph,
except for any cycles. In the worst case with a highly connected graph,
this search can take exponential time. In practice, this means that in
cases with long dependency chains and multiple packages depending on the
same package, the hook can take several hours to run.
Avoid this problem by keeping track of already visited paths and only
visiting each path once. This makes the search complete in linear time.
The visible effect of this change is that, if a conflict is found, only
one dependency chain that leads to the conflicting package is printed,
rather than all the possible dependency chains.
Add a test where a conflicting package can be found at the end of
multiple dependency chains. This is far too simple an example to
demonstrate the ill effects of exponential time complexity, but does
serve to demonstrate how the error output changes when each path is only
visited once.
Broken since the switch to PyPA's build/installer in
6c85fff302.
The hook was always janky and maintainers appear to not want its current
implementation in-tree. No replacement is currently planned.
However, this leaves the path open for future replacements as a broken
hook will no longer be installed by default.
Prevent the hook from erroring out on missing specifiers, as reported for
`highspy`, which currently ships with a pre-release version, triggering
the following error message:
- highspy not satisfied by version 1.7.1.dev1
When building a python environment's bin directory, we now detect
wrapped python scripts from installed packages, and generate unwrapped
copies with the environment's python executable as the interpreter.
The way we build python environments is subtly broken. A python
environment should be semantically identical to a vanilla Python
installation in, say, /usr/local. The current implementation, however,
differs in two important ways. The first is that it's impossible to use
python packages from the environment in python virtual environments. The
second is that the nix-generated environment appears to be a venv, but
it's not.
This commit changes the way python environments are built:
* When generating wrappers for python executables, we inherit argv[0]
from the wrapper. This causes python to initialize its configuration
in the environment with all the correct paths.
* We remove the sitecustomize.py file from the base python package.
This file was used tweak the python configuration after it was
incorrectly initialized. That's no longer necessary.
The end result is that python environments no longer appear to be venvs,
and behave more like a vanilla python installation. In addition it's
possible to create a venv using an environment and use packages from
both the environment and the venv.
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.
Albeit counter-intutive, the `propagatedBuildInputs`
mechanism and the corresponding package files in
`nix-support/propagated-build-inputs`
can form a dependency cycle.
This can happen if a package adds itself to this file,
or if multiple outputs of one derivation reference each other.
An example for this is the `patchPpdFilesHook`:
In its mission to collect dependency packages with binaries
that might be required by the dependent package to be created,
it sometimes picks up the dependent package itself.
This indicates that if a file of the dependent package
is used, the package itself should also be installed.
In the case of a multiple output package,
it is also possible that two outputs depend on each other,
creating a dependency cycle.
Since commit 2651ddc7b0,
the `find_packages` function in `catch_conflicts.py`
recursively collects all `propagated-build-inputs` files.
If it encounters a dependency cycle, it must not follow the
cycle to avoid infinite recursion (and a stack overflow).
The commit at hand adds a check so that the function skips over
a package that it already encountered and processed earlier.
This does not loosen the script's checks as the script
still recursively collects all propagated build inputs.
Ben Wolsieffer