Without this flag, the configure script prints a warning at the end,
like this (reformatted):
If you want a release build with all stable optimizations active
(PGO, etc), please run ./configure --enable-optimizations
We're doing a build to distribute to people for day-to-day use,
doing things other than developing the Python interpreter. So
that's certainly a release build -- we're the target audience for
this recommendation.
---
And, trying it out, upstream isn't kidding! I ran the standard
benchmark suite that the CPython developers use for performance
work, "pyperformance". Following its usage instructions:
https://pyperformance.readthedocs.io/usage.html
I ran the whole suite, like so:
$ nix-shell -p ./result."$variant" --run '
cd $(mktemp -d); python -m venv venv; . venv/bin/activate
pip install pyperformance
pyperformance run -o ~/tmp/result.'"$variant"'.json
'
and then examined the results with commands like:
$ python -m pyperf compare_to --table -G \
~/tmp/result.{$before,$after}.json
Across all the benchmarks in the suite, the median speedup was 16%.
(Meaning 1.16x faster; 14% less time).
The middle half of them ranged from a 13% to a 22% speedup.
Each of the 60 benchmarks in the suite got faster, by speedups
ranging from 3% to 53%.
---
One reason this isn't just the default to begin with is that, until
recently, it made the build a lot slower. What it does is turn on
profile-guided optimization, which means first build for profiling,
then run some task to get a profile, then build again using the
profile. And, short of further customization, the task it would use
would be nearly the full test suite, which includes a lot of
expensive and slow tests, and can easily take half an hour to run.
Happily, in 2019 an upstream developer did the work to carefully
select a more appropriate set of tests to use for the profile:
https://github.com/python/cpython/commit/4e16a4a31https://bugs.python.org/issue36044
This suite takes just 2 minutes to run. And the resulting final
build is actually slightly faster than with the much longer suite,
at least as measured by those standard "pyperformance" benchmarks.
That work went into the 3.8 release, but the same list works great
if used on older releases too.
So, start passing that --enable-optimizations flag; and backport
that good-for-PGO set of tests, so that we use it on all releases.
Each time a new major/minor version of CPython was released, a new
expression would be written, typically copied from the previous release.
Often fixes are only made in the current/latest release. By merging the
expressions it's more likely that modifications end up in all versions,
as is likely intended.
This commit introduces one expression for Python 3, and another for 2.7.
These two may also be merged, but it will result in a lot of extra
conditionals making the expression harder to follow.
A common passthru is introduced for CPython and PyPy.
python 2.7: use common passthru
upstream issue:
https://bugs.python.org/issue31940
There are two PR's proposed to fix this,
but both seem to be stalling waiting for review.
I previously used what appears to be the favored
of the two approaches[1] to fix this,
with plan of keeping it musl-only until PR was merged.
However, while writing up a commit message
explaining the problem and why it needed fixing...
I investigated a bit and found it increasingly
hard to justify anything other than ...
simply not using lchmod.
Here's what I found:
* lchmod is non-POSIX, seems BSD-only these days
* Functionality of lchmod isn't supported on Linux
* best scenario on Linux would be an error
* POSIX does provide lchmod-esque functionality
with fchmodat(), which AFAICT is generally preferred.
* Python intentionally overlooks fchmodat()[2]
electing instead to use lchmod() behavior
as a proxy for whether fchmodat() "works".
I'm not sure I follow their reasoning...
* both glibc and musl provide lchmod impls:
* glibc returns ENOSYS "not implemented"
* musl implements lchmod with fchmodat(),
and so returns EOPNOTSUPP "op not supported"
* Python doesn't expect EOPNOTSUPP from lchmod,
since it's not valid on BSD's lchmod.
* "configure" doesn't actually check lchmod usefully,
instead checks for glibc preprocessor defines
to indicate if the function is just a stub[3];
somewhat fittingly, if the magic macros are defined
then the next line of the C source is "choke me",
causing the compiler to trip, fall, and point
a finger at whatever is near where it ends up.
(somewhat amusing, but AFAIK effective way to get an error :P)
I'm leaving out links to threads on mailing lists and such,
but for now I hope I've convinced you
(or to those reading commit history: explained my reasons)
that this is a bit of a mess[4].
And so instead of making a big mess messier,
and with hopes of never thinking about this again,
I propose we simply tell Python "don't use lchmod" on Linux.
[1] https://github.com/python/cpython/pull/4783
[2] 28453feaa8/Lib/os.py (L144)
[3] 28453feaa8/configure (L2198)
[4] Messes happen, no good intention goes unpunished :).
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.
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.
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
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.
