This was generated with a regex search/replace in vscode using:
`(open\(.*, 'w\+?')` -> `$1, encoding='utf-8')`
This should silence a bunch of warnings, and seems to fix issues seen in
the Windows CI. This seems to likely be to a "helpful feature" in
msbuild that treats certain text in stdout/stderr as errors, which it
sometimes decides that the warning about not having the encoding set
triggers.
Skip the limited API test when the CPython version used indicates
being built with GIL disabled, i.e. the freethreaded build.
The freethreaded versions of Python 3.13 and 3.14 do not support
the limited API, and attempting to build the test case results
in compilation failures.
The check is limited to <3.15, so we don't forget to reenable it
once limited API is supported.
Signed-off-by: Michał Górny <mgorny@quansight.com>
We check to see if a test extension exists, and if so add its path to
sys.path... immediately before unconditionally importing it, obviously.
This raises the question: why bother checking? Can it ever fail? What if
it does fail, do we simply not add path entries and then expect the rest
of the test file to work??? The whole thing seems silly and useless.
In fact it can fail, if the python interpreter and/or standard library
is broken. This is the case for the initial release of PyPy 3.11, in
which `'*tachyon*'` fails to glob correctly (and `'tachyon*'` would
work, funnily enough -- this is valid too for our use case although
still just as pointless).
Delete the useless check. It's technically correct to delete it, and it
*also* works around the PyPy breakage as a bonus.
Closes: https://github.com/mesonbuild/meson/issues/14307
Based on the example in GH issue #13167, the limited API test has been
extended with a test to load the compiled module to ensure it can be
loaded correctly.
0e7fb07 introduced a subtile bug in the Python module.
If a python version is found, but is missing a required module,
it is added to the list of python installations, but the
`run_bytecompile` attribute for that version was not initialized.
Therefore, if any other python version added something to install, it
was raising a KeyError when trying to read the `run_bytecompile`
attribute for the python version with missing module.
Testing the correctness of the `modules: ` kwarg can be done with other
guaranteed stdlib modules that are even more guaranteed since they
didn't get deprecated for removal.
This commit adds a new keyword arg to extension_module() that enables
a user to target the Python Limited API, declaring the version of the
limited API that they wish to target.
Two new unittests have been added to test this functionality.
Since CPython 3.8 .pyd files no longer look in PATH for loading libraries,
but require the DLL directory to be explicitely added via os.add_dll_directory().
This resulted in those tests failing with 3.8+ on Windows.
Add the DLL build directory with os.add_dll_directory() to fix them.
This was never noticed in CI because it only uses Python 3.7 and the
MSYS2 CPython still used the old behaviour until now.
This matches the tests for Python extensions.
Also include some other cleanups to these `meson.build` files:
Adding `python_dep` is no longer needed, this is automatic now.
Use a single line for `import('python').find_installation()`,
because the result of `import('python')` by itself is not used
for anything.
For all source `*.py` files installed via either py.install_sources() or
an `install_dir: py.get_install_dir()`, produce `*.pyc` files at install
time. Controllable via a module option.
import('python').find_installation('python').version() causes exception
because of a missing initialization, when `find_installation()` receives
a name or a path.
It can only be used for projects that don't have any rules at all, i.e.
they are purely using Meson to:
- configure files
- run (script?) tests
- install files that exist by the end of the setup stage
This can be useful e.g. for Meson itself, a pure python project.
In a couple of python module tests, we try to test things that rely on
the default python being the same one we look up in the python module.
This is unsolvable for the deprecated python3 module, as it actually
uses the in-process version of python for everything. For the python
module, we could actually look up the default system python instead of
the one we are running with, but then we wouldn't be testing the
functionality of that alternative python... and also the install
manifest tests would see files installed for the wrong version of
python, and report a combination of missing+extra files...
Solve both tests by just skipping the parts we cannot check.
Apparently Azure provides 64-bit python2 when we try to test 32-bit, and
that breaks everything on the 32-bit test runner.
I don't understand the environment setup, and that runner is
disappearing soon anyway. Hopefully this shuts up the known breakage.
Perhaps when this test case was originally created, project tests could
not use a matrix of options? This is certainly possible today, so don't
write special unittest handling for this instead.
This adds proper visibility into what gets run and what doesn't. Now we
know which python executables got tested and which got skipped.
This mirrors the modules keyword argument that some dependencies (such
as qt and llvm) take. This allows an easier method to determine if
modules are installed.
This doesn't touch everything as it's just based on the python3 module
tests, ported to the python module. It's still better than the one very
basic test in the unit test module.
