-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pip install . --user -> [Errno 2] No such file or directory: 'meson' #109
Comments
Did you link the wrong pull request? All that does is add
It'd be good to have this work. It should not be necessary though, more recent
This seems fine to me as a fix for |
It's not necessarily true if you use for example This could be relevant for e.g. Gentoo, where multiple versions of python are supported, but on the other hand they do have meson-python depend on Perhaps @thesamesam could clarify whether this matters. |
I am not sure what to say, the |
Not necessarily, we will use whatever Meson to build, but we do tell Meson which Python interpreter to use. Ideally, Meson would always be provided by the environment we are running on, and that is true in isolated build, but there might be situations when running without isolation where that might not be the case. |
I cannot reproduce this with SciPy,
That pull request does not seem related. I also searched the I had a look in detail at the build log. It reads:
This looks like user error. The @Nic30 am I missing something, or can be close this as invalid? |
I think it would be beneficial for you to describe your dev environment setup. Other thought, have you updated your pip? This can happen when building without isolation if the dependency is missing, though I assumed pip would be able to notice the missing dependency. |
Hello,
I am using: https://github.com/Nic30/hwtHls/blob/llvm_mir_integration/pyproject.toml
There is the log from build: docker-build.log
(I also used
|
Hmm, maybe there's a difference between explicitly using |
No it is the same docker-build.log @rgommers (or anyone else with working meson-python) What system, python, pip do you use? |
I'm using both Arch Linux and macOS, conda-forge environments, Python 3.8-3.10, and usually latest |
I recently switched dbus-python to use Meson and If I run pip with more debugging enabled, it produces some information that could be useful:
I hacked in some debugging, and it looks as though pip is installing The workaround is to install |
Oh, that makes sense, thank you for posting that output! This is another issue cause by Debian's patching of Python. As a workaround, we can try to add that missing directory to |
I've reported this as https://bugs.debian.org/1019293. I think it's a bug in one of two Debian packages: either |
I think this is a variation of pypa/pip#11539 fixed in pypa/pip#11598 Namely pip does not setup correctly the isolated environment for the build. It would be nice if you could test with a pip with that patch applied. |
I tried
And it seems that the issue is still there. |
I see. The issue is with the binary path, not with the library path. The linked patch solved the latter, not the former. The issue is caused by this code in pip https://github.com/pypa/pip/blob/5f3f592c4581a059ff9de0fb8052ef5c6ef25fd4/src/pip/_internal/build_env.py#L40-L43 and by Debian patching @smcv on which Debian release did you encounter the problem? Never mind, the info is in the linked debbug. |
In particular, >>> sysconfig.get_default_scheme()
'posix_local'
>>> sysconfig.get_paths('posix_local', vars={'base': '{prefix}'})['scripts']
'{prefix}/local/bin' but, per the code snippet linked above, it sets >>> sysconfig.get_paths('posix_prefix', vars={'base': '{prefix}'})['scripts']
'{prefix}/bin' The same scheme should be used for installation and binary path lookup. I don't know which one of the two used here is the right one. Although, setting the scheme as is done in the linked snippet seems suspicious, as |
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
@smcv @Nic30 can you please check if pypa/pip#11623 fixes your issue? Edit: I reproduced the issue in a Debian sid container and I verified that the linked patch fixes the issue. |
meson-python tests did not catch the issue because we don't run them in an environment without meson installed in the system |
It works for meson but it breaks path for other apps installed on the
host, in my case for cmake which I am using to build a subproject. So it
works but this new path should be just appended (not overwritten).
This aspect is not changed. The path is prepended to the existing $PATH
environment variable. Also note that in the log Meson reports that it
found gcc, thus $PATH is most likely sane. CMake may be missing for
other reasons.
|
which is misleading. But this is other issue. |
The exception splat is already fixed in #231. With only this error message snippet is not possible to determine what is the root cause of the problem. |
There was just some missing include in cmake subproject. What I wanted to say is that your fix for pip works. |
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes. However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293. The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.
pip 23.0.1 has just been released and it should solve all problems related to isolated build environments setup. |
Hello,
I am trying to make package build by meson-python installable by pip using
pip install --user .
(a complete build script, CI config)Recent changes in pip broke this and mesonpep517 has the same issue
jeandet/mesonpep517#1 (comment)
mesonpep517 has opened pull request which is fixing this, however merging takes some time and I simply need this so I tried meson-python.
The result is the same:
There is a full log from build
The problem is that pip does modify the PATH and meson executable will be missing. Note that this happens only if meson is not installed in the advance.
You can fix it by executing meson as a module function and not as an executable, as you are currently doing https://github.com/FFY00/meson-python/blob/main/mesonpy/__init__.py#L477 . (see changes in mesonpep517 pull request). (Note that the user typically does not have meson installed in advance.)
Ubuntu 22.04 LTS
The text was updated successfully, but these errors were encountered: