| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On Python 3.8.x and later, if the imported module requires non-system DLLs that
are not installed nor bundled with the module package, os.add_dll_directory()
must be called on every path that contains the required DLLs, so that the module
can be imported successfully by Python.
Make things easier for people by calling os.add_dll_directory() on the
valid directories in %PATH%, so that such module checks can be carried out
successfully with much less manual intervention.
|
|
|
|
This is more reliable as '-c' can, for example, exhaust
the maximum command line length.
|
|
This check was erroneously removed in commit c5c02b72e132a03ae0284bdd5e15d1675301a37d
|
|
It was originally added because proper detection was not working on
Debian, but that has been fixed since. It was causing annoying warning
by default when prefix is /usr/local that can only be avoided by setting
options.
|
|
This reverts commit 79c6075b560dbf1c3e4e0b30f1c472dc2086421e.
# Conflicts:
# docs/markdown/snippets/devenv.md
# mesonbuild/modules/python.py
# test cases/unit/91 devenv/test-devenv.py
PYTHONPATH cannot be reliably determined. The standard use case for
installing python modules with Meson is mixed pure sources (at least
`__init__.py`) and compiled extension_modules or configured files.
Unfortunately that doesn't actually work because python will not load
the same package hierarchy from two different directories, one a source
directory and one a (mandatory) out of tree build directory.
(It kind of can, but you need to do what this test case accidentally
stumbled upon, which is namespace packages. Namespace packages are a
very specific use case and you are NOT SUPPOSED to use them outside that
use case, so people are not going to use them just to circumvent Meson
devenv stuff as that would have negative install-time effects.)
Adding PYTHONPATH anyway will just lead to documentation commitments
which we cannot actually uphold, and confusing issues at time of use
because some imports *will* work... and some will *not*. The end result
will be a half-created tree of modules which just doesn't work together
at all, but because it partially works, users attempting to debug it
will spend time wondering why parts of it do import.
For any case where the automatic devenv would work correctly, it will
also work correctly to use `meson.add_devenv()` a single time, which is
very easy to manually get correct and doesn't provide any significant
value to automate.
In the long run, an uninstalled python package environment will require
"editable installs" support.
|
|
This prints many lines of unwanted "done /absolute/path",
I noticed this when testing 0.62.0rc1 with SciPy.
[ci skip]
|
|
There are two cases where we can assume we found the python dependency
with its requisite libraries using sysconfig:
- we found the library with find_library and are prepared to link to it
- the library is not actually part of the dependency, so its presence or
absence is irrelevant
In the latter case, we should consider it found if link_libpython is
False. Originally we did this, but the logic was inverted in commit
5b422fce87826beff3bca85e9c9081f22b3f45b7 in an unrelated change and
without explanation, likely by accident.
Normally this doesn't much matter, since a python invariably comes with
a predictably located libpython and the first condition evaluates true.
But that is not true for pypy, and in fact that is the reason the
link_libpython check was originally added in commit
1bd14b52b26b0f4ec207bf7e38813b82bfc15f86.
Restore that original logic.
Fixes #8570
|
|
A bunch of files have several T.TYPE_CHECKING blocks that each do some
things which could just as well be done once, with a single `if`
statement. Make them do so.
|
|
|
|
This avoids running sanity checks everytime find_installation() is
called.
|
|
The default behavior of installing relative to prefix may be unexpected,
and is definitely wrong in many cases.
Give users control in order to specify that yes, they actually want to
install to a venv.
This is particularly useful for projects that use meson as a build
system for a python module, where *all* files shall be installed into
the python site-packages.
|
|
If the found python returns None from sysconfig.get_config_var('LIBPC')
then we cannot (and don't) set PKG_CONFIG_LIBDIR from it. In fact, we
can virtually guarantee we won't find a PkgConfigDependency either,
because any python that doesn't have a LIBPC is presumably not installed
to the system pkg-config directory (maybe it's an isolated relocatable
install, maybe it just doesn't have pkg-config support for who knows
what reason).
Trying to find one anyway using pkg-config's builtin search paths can
unexpectedly succeed, though, by finding a completely unrelated python
installation installed to a system location, which isn't the one we are
actually building for.
Instead, return early so that we use the system dependency class
fallback.
While we are at it, add back the debug messages from #3989 which got
removed.
|
|
Virtualenvs do not have their Python DLLs etc in the `sys.prefix`
directory, but in the `sys.base_prefix` directory. This directory is
the same as `sys.prefix` if not in a virtualenv, so is safe for either
case:
https://docs.python.org/3/library/sys.html#sys.base_prefix
|
|
Using pathlib ensure propre platform specific path handling, such as
case sensitivity.
|
|
It has to lookup the dependency with required=False otherwise it raises
an exception when the first candidate (pkg-config) failed.
|
|
|
|
The dep.name() function schould always return the name of the
dependency as documented. No matter if it was found or not.
https://mesonbuild.com/Reference-manual_returned_dep.html#depfound
|
|
|
|
|
|
|
|
Hardcoding the name is fragile, and enabling it based on the existence of
/etc/debian_version (as the is_debianlike helper does) will result in
incorrect paths if the Python binary is not provided by Debian.
Using the deb_system distuils scheme instead makes sure we use the
install path from the current interpreter, which Debian could change
between releases, and gives us the correct value on Python installations
that are not provided by Debian (eg. deadsnakes, Github Action Python,
etc.)
Do notice, though, that there is still no guarantee that these are the
correct paths, as they assume all schemes paths have the install prefix
as a base, see #9284.
Signed-off-by: Filipe LaÃns <lains@riseup.net>
|
|
Signed-off-by: Filipe LaÃns <lains@riseup.net>
|
|
We use distutils, not setuptools, for probing information.
|
|
There is a unit test using it and now fails because the warning about
unknown kwarg became fatal.
|
|
The correct way to mark these is `KwargInfo(..., (T, type(None)))`.
There's also a few cases of `(T, None)` which is invalid, as `None`
isn't a type
|
|
The sysconfig paths are, by default, correct for every OS -- they are
supposed to follow the scheme that python knows about per default.
For some reason, this overrode the scheme to posix_prefix, which is the
default for posix OSes like linux and macOS, but wrong on Windows.
Simply deleting this entirely makes everything that used to work, still
work, and a couple new things start working.
|
|
|
|
They are documented to go in site-packages, and indeed belong there.
Regression from the initial implementation via commit ad296976f079cd185ab7361e3e4b18c6bf684090
Fixes #6331
|
|
Basically just reorganize code. Try to make it a little neater, while
we're at it.
|
|
It is always set to python3 even if we asked for python2...
|
|
rsplit(..., 1) always produces exactly one split, by design, there's no
need to then join a 1-element list via a generator comprehension after
extracting the end of it via pop. If this commit message sounds
confusing, then so was I when trying to figure out what this actually
did and if it needed extracting to PythonExternalModule.
|
|
Fixes: #7007.
|
|
|
|
These were spotted by mypy and pyright. One is a string where a Path is
expected, another other is a possibly unbound variable, and the third is
bound but unused variables.
|
|
|
|
|
|
This removes the odd 'pkgdep' attribute thing, and makes it behave more
like a proper dependency
|
|
Including not calling back into `Interpreter.func_*`, which is not a
good idea both from a type saftey and perforamance point of view.
Instead there's now a shared _impl method
|
|
And note that the way that find_installation works is completely broken
in regards to machine files
|
|
There's still a number of things that don't properly type check, that's
expected though as the input is often unvalidated and assumed good.
|
|
|
|
|
|
mesonbuild.dependencies.__init__ exposes configtool, pkgconfig, cmake
and more in __init__.py, so there's no reason we should be tying
SystemDependency to the internal organization implementation of the
subpackage!
In the 2nd previous commit it took quite some effort to figure out that
the python module "does not exist" because of import errors while
refactoring something completely different.
|
|
In accordance with review comments; it's small enough this seems fitting.
|
|
This fixes these dependencies, which currently return the name of the
dependency as the type.
Fixes #8877
|
|
Split the Factory and dependency classes out
of the base.py script to improve maintainability.
|
|
This fix calling random internal methods from meson.build as long as
they were not prefixed by underscore.
|
|
The only advantage they have is they have the interpreter in arguments,
but it's already available as self.interpreter. We should discourage
usage of the interpreter API and rely on ModuleState object instead in
the future.
This also lift the restriction that a module method cannot add build
targets, but that was not enforced for snippet methods anyway (and some
modules were doing it) and it's really loose restriction as it should
check for many other things if we wanted to make it consistent.
|
|
|
