Wrappers already included `PYTHONNOUSERSITE=1`, but now this env var is
also set in the Python setup hook. This improves purity in case of
non-sandboxes builds and nix-shell.
When a Python script has the extension `.py`, bytecode is generated.
Typically, executables in bin have no extension, so no bytecode is
generated. However, some packages do provide executables with
extensions, and thus bytecode is generated.
28299f669a introduced the first Python
packages having multiple outputs. The required outputs were not picked
up by `python.buildEnv` (#31857).
This commit modifies `python.buildEnv` so that it always includes the
$out output and thus fixes#31857.
Python libraries or modules now have an attribute `pythonModule = interpreter;` to indicate
they provide Python modules for the specified `interpreter`.
The package set provides the following helper functions:
- hasPythonModule: Check whether a derivation provides a Python module.
- requiredPythonModules: Recurse into a list of Python modules, returning all Python modules that are required.
- makePythonPath: Create a PYTHONPATH from a list of Python modules.
Also included in this commit is:
- disabledIf: Helper function for disabling non-buildPythonPackage functions.
This continues #23374, which always kept around both attributes, by
always including both propagated files: `propgated-native-build-inputs`
and `propagated-build-inputs`. `nativePkgs` and `crossPkgs` are still
defined as before, however, so this change should only barely
observable.
This is an incremental step to fully keeping the dependencies separate
in all cases.
In the maintenance release bump in
90059701a8 a certain change to /test/ was
backported from Python 3:
- bpo-30207: To simplify backports from Python 3, the test.test_support
module was converted into a package and renamed to test.support. The
test.script_helper module was moved into the test.support package.
Names test.test_support and test.script_helper are left as aliases to
test.support and test.support.script_helper.
libffi needs a patch to actually work on aarch64 (or the cffi Python package
fails its testsuite). Of course the bundled version of libffi has the
same bug, so don't use the buggy version on aarch64.
Python3 already uses the system libffi on all platforms. I don't know
why Python2 doesn't.
While we tell pip not to fetch (with the `--no-index` option),
`setuptools` can do so itself. In the past we used a `distutils.cfg`
with `allow-hosts = None` to prevent setuptools from fetching itself.
This was removed when we started building wheels in
2562f94de4e4fd2ddc677187fa2e2848L69.
The `dist-utils.cfg` code was still there, and adding it to
`buildInputs` is sufficient.
Tested with python.pkgs.passlib by removing the `checkInputs` / `nose`.
test.{support, regrtest} are the internal packages cpython
developers use to write tests.
Although they are not public and the API may change/break
some developers use these packages to write tests for their
(3rd party) software.
The derivations for cpython now only remove the actual tests
but leave the packages in place that are used to write them.
Discussion: https://github.com/NixOS/nixpkgs/pull/28540
Symbolic links were added pointing to the executables that end with 3 as
part of the Python 2 to 3 migration. At some point I disabled ensurepip
but forgot to remove this symbolic link.
Symbolic links were added pointing to the executables that end with 3 as
part of the Python 2 to 3 migration. At some point I disabled ensurepip
but forgot to remove this symbolic link.
Symbolic links were added pointing to the executables that end with 3 as
part of the Python 2 to 3 migration. At some point I disabled ensurepip
but forgot to remove this symbolic link.
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
Python envs did not pass through any of the properties the Python
interpreter has. That could be annoying, especially not having
`python.interpreter` which is the path to the interpreter. This commit
fixes the situation and inherit python.passthru.
Thus far all executables in a derivation were wrapped. This commit
only wraps executables in $out/bin. If other scripts need to be wrapped
as well, then one can use wrapPythonProgramsIn.
When tests are disabled, we do not want to pass checkInputs to
stdenv.mkDerivation. This reduces the build requirements and, more
importantly, helps cutting cycles.
The Python interpreters are patched so they can build .pyc bytecode free
of certain indeterminism.
When building Python packages we currently set
```
compiling python files.
in nix store.
DETERMINISTIC_BUILD=1;
PYTHONHASHSEED = 0;
```
Instead if setting these environment variables in the function that
builds the package, this commit sets the variables instead in the Python
setup hook. That way, whenever Python is included in a derivation, these
variables are set.
See also the issue https://github.com/NixOS/nixpkgs/issues/25707.
This commit fixes several issues:
- as reported in https://github.com/NixOS/nixpkgs/issues/24924 it was
possible that the file _sysconfigdata.pyc was generated after the actual
build of the CPython interpreter. We forgot to regenerate that file
during the build. This is now fixed
- the expression of the 3.3 interpreter now also includes some of the
determinism patches even though the output isn't yet reproducible. The
reason for adding them is that this makes the expressions of the
different interpreters more similar.
- references to -dev packages are now also removed in the 3.6 package,
thereby reducing its closure size
Python does add the script's directory into "sys.path". For the case of
"catch_conflicts.py" this means "/nix/store" is added to "sys.path". This can
result in very long delays if the store contains a lot of entries.
(moved from master commit 76213d102c)
From the manual:
> This attribute should be a number, with a higher value denoting a
lower priority. The default priority is 0.
Just passing -5 or -10 wasn't sufficient, so let's make it -100.
- Windows installers are indeterministic and we don't need them.
- since Python 3 ensurepip is installed by default. pip is indeteministic and we don't need it.
- rebuild bytecode to ensure its deterministic
Certain programs, like zim, calibre and now also apparently mercurial,
rely on sys.argv[0] providing not just the script name but the full
path.
The Python docs [1] state the following on the matter:
> argv[0] is the script name (it is operating system dependent whether
this is a full pathname or not).
Therefore, scripts should not expect to receive a full path.
Unfortunately some do. While this can be considered a bug, there doesn't
seem any reason not to provide the full path. Therefore we now provide
the full path.
[1]
https://docs.python.org/3.5/library/sys.html?highlight=sys.argv#sys.argv
A package set is constructed for a specific interpreter. Therefore, we add the
possibility to override the package set to the interpreter. This should make it
easier to override the interpreter and the package set at the same time.
In #19309 a separate output for tkinter was added.
Several dependencies of Python depend indirectly on Python. We have the
following two paths:
```
‘python-2.7.12’ - ‘tk-8.6.6’ - ‘libXft-2.3.2’ - ‘libXrender-0.9.10’ -
‘libX11-1.6.4’ - ‘libxcb-1.12’ - ‘libxslt-1.1.29’- ‘libxml2-2.9.4’ -
‘python-2.7.12’
‘python-2.7.12’ - ‘tk-8.6.6’ - ‘libXft-2.3.2’ - ‘fontconfig-2.12.1’ -
‘dejavu-fonts-2.37’ - ‘fontforge-20160404’ - ‘python-2.7.12’
```
Because only `tkinter` needs this, I added
```
pythonSmall = python.override {x11Support = false;};
```
to break the infinite recursion. We also still have the output
`tkinter`.
However, we might as well build without x11Support by default. Then we build with x11Support as well so we get the tkinter module and put that in a separate package.
python.buildenv is used to build an env that provides binaries that can
import all modules that were passed in to the env.
Before this change it filtered the propagatedBuildInputs to remove all
non-Python packages, thereby possibly reducing the amount of packages
that were referenced. However, Python packages often don't have non-
Python packages as propagatedBuildInputs. And occasionally, we do want
to be able to add other packages to the env.
It's a long build and generally painful to split into smaller commits,
so I apologize for lumping many changes into one commit but this is far
easier.
There are still several outdated parts of the darwin stdenv but these
changes should bring us closer to the goal.
Fixes#18461
Compiling python with "-Wl,-stack_size,1000000" causes problems when
compiling for example pygobject3. pygobject3 uses "python3.x-config
--ldflags" during installation and then fails when
"-Wl,-stack_size,1000000" is present. Maybe we should investigate
removing this during the build of pyobject3, but this stack_size flag is
also not used on the popular darwin homebrew-core channel for python3.5,
so it seems safe to remove it.
This one was already merged into release-16.09, so let's not have the
stable branch is ahead of master and confuse things. In addition to
that, currently we have an odd situation that master has less things
actually finished building than in staging.
Conflicts:
pkgs/data/documentation/man-pages/default.nix
