* ``sys.executable`` is not set
* WASI does not support subprocess
* ``pwd`` module is not available
* WASI checks ``open`` syscall flags more strict, needs r, w, rw flag.
* ``umask`` is not available
* ``/dev/null`` may not be accessible
Add methods enterContext() and enterClassContext() in TestCase.
Add method enterAsyncContext() in IsolatedAsyncioTestCase.
Add function enterModuleContext().
* Removes SO config variable in sysconfig
Per @warsaw in https://github.com/python/cpython/issues/63754, this was
deprecated in Python 3.4 and was suggested for removal in Python 3.5.
* Add NEWS
* Update Misc/NEWS.d/next/Library/2022-04-18-15-23-24.gh-issue-91670.6eyChw.rst
Co-authored-by: Éric <merwok@netwok.org>
Co-authored-by: Barry Warsaw <barry@python.org>
Co-authored-by: Éric <merwok@netwok.org>
- getgroups always fails.
- geteuid and getegid always return 0 (root), which confuse tarfile and
tests.
- hardlinks (link, linkat) always fails.
- non-encodable file names are not supported by NODERAWFS layer.
- mark more tests with dependency on subprocess and multiprocessing.
Mocking does not work if the module fails to import.
A previous commit broke a check in sysconfig when building cpython itself.
This caused builds of the standard library modules to search a wrong
location (the installed location rather than the source directory) for
header files with the net effect that a ``make install``
incorrectly caused all extension modules to be rebuilt again and
with incorrect include file paths.
When building Python, we need two distinct "include" directories:
- source .h files
- install target for .h files
Note that this doesn't matter except when building Python from source.
Historically:
- source .h files were in the distutils scheme under 'include'
- the install directory was in the distutils.command.install scheme
under 'headers'
GH-24549 merged these; sysconfig is now the single source of truth and
distutils is derived from it.
This commit introduces a "secret" scheme path, 'headers', which contains
the install target. It is only present when building Python.
The distutils code uses it if present, and falls back to 'include'.
Co-authored-by: Ned Deily <nad@python.org>
Only complain if the config target is >= 10.3 and the current target is
< 10.3. The check was originally added to ensure that incompatible
LDSHARED flags are not used, because -undefined dynamic_lookup is
used when building for 10.3 and later, and is not supported on older OS
versions. Apart from that, there should be no problem in general
with using an older target.
Authored-by: Joshua Root <jmr@macports.org>
This change:
* merges `distutils.sysconfig` into `sysconfig` while keeping the original functionality and
* marks `distutils.sysconfig` as deprecated
https://bugs.python.org/issue41282
With this patch, `distutils.command.install.INSTALL_SCHEMES` are loaded from
`sysconfig._INSTALL_SCHEMES`.
The distutils module is deprecated and will be removed in 3.12 (PEP 632).
This change makes the `sysconfig._INSTALL_SCHEMES` the single point of truth
for install schemes while keeping `distutils.command.install.INSTALL_SCHEMES`
exactly the same. If we, during the transition to the sysconfig, change
something, this makes sure that it also propagates to distutils until the
module gets removed.
Moreover, as discussed [on Discourse], Linux distros need to patch
distutils/sysconfig to make sure the packages will land in proper locations.
This patch makes it easier because it leaves only one location where install
schemes are defined which is much easier to patch/adjust.
[on Discourse]: https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134
The implementation is slightly different than the plan but I think it's the
easiest way how to do it and it also makes the downstream patch simple,
flexible and easy to maintain.
It's also necessary to implement this before setuptools starts bundling
the distutils module so the default install schemes stay in the standard library.
The removed code from sysconfig does not seem to have any negative effect
because, honestly, it seems that nothing actually uses the install schemes
from sysconfig at all. There were many big changes in these modules where
they were trying to include packaging in stdlib and then reverted that.
Also, the test of distutils install command does not count with the different
locations which is good evidence that the reason to have this piece of code
is no longer valid.
https://bugs.python.org/issue41282
The following changes are required:
* add a new platform win-arm64
* replace the emulated compiler executable paths
* bump the linker base addressed as ARM64 requires more memory
this change might not be needed (investigation required)
On Windows 10 ARM64, VS compiler paths look like this:
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\HostX86\ARM64\cl.exe
Note that the cl.exe for ARM64 is an x32 binary, which can run emulated
on Windows 10 ARM64 (it has builtin emulation for x32).
The rc.exe and mc.exe paths have to also be changed, as the initial
discovery has to be fixed.
Work in progress to remove the hardcoded bits and to change the path
query fixes to the proper location.
Automerge-Triggered-By: GH:jaraco
The distutils bdist_wininst command deprecated in Python 3.8 has been
removed. The distutils bidst_wheel command is now recommended to
distribute binary packages on Windows.
* Remove Lib/distutils/command/bdist_wininst.py
* Remove PC/bdist_wininst/ project
* Remove Lib/distutils/command/wininst-*.exe programs
* Remove all references to bdist_wininst
macOS releases numbering has changed as of macOS 11 Big Sur. Previously, major releases were of the form 10.x, 10.x+1, 10.x+2, etc; as of Big Sur, they are now x, x+1, etc, so, for example, 10.15, 10.15.1, ..., 10.15.7, 11, 11.0.1, 11.1, ..., 12, 12.1, etc. Allow Python to build with single-digit deployment target values. Patch provided by FX Coudert.
On macOS system provided libraries are in a shared library cache
and not at their usual location. This PR teaches distutils to search
in the SDK, even if there was no "-sysroot" argument in
the compiler flags.
Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com>
* Add support for macOS 11 and Apple Silicon (aka arm64)
As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy
* Support building on recent versions of macOS while deploying to older versions
This allows building installers on macOS 11 while still supporting macOS 10.9.
Christian Heimes
Irit Katriel
Jeremy Kloth
Victor Stinner
Serhiy Storchaka
Bryan Weber
Brett Cannon
Hugo van Kemenade
Christian Clauss
Mohamad Mansour
Noah Kantrowitz
Leonardo Freua
Lumír 'Frenzy' Balhar
Petr Viktorin
Sebastian Rittau
Ned Deily
Lumír 'Frenzy' Balhar
Jason R. Coombs
Adrian Vladu
Inada Naoki
Zackery Spytz
Ronald Oussoren
Steve Dower
pxinwr
FX Coudert
Hai Shi