Already one weird failure, on the musllinux job:

picking up the wrong `meson`: ['/__w/numpy/numpy/test_env/lib/python3.10/site-packages/mesonbuild']

that __w path looks very odd, doesn't immediately ring a bell.

I think the _w is a false flag, it has to do with the container file system. It seems more like there is a problem with sys.path injection, perhaps the git submodule update --init did not work.

There is an error in the log

Could not access submodule 'vendored-meson/meson' at commit 45e98f381

Could not access submodule 'vendored-meson/meson' at commit 45e98f381

Good catch - that is a little curious. Guess I'll need to add a check for that. I fixed the other (lint, sdist) failures. Let's see if it happens again. The other submodules did get initialized, so it's unclear to me what the problem was there.

musl linux is cloning, and then fetching this PR (which has a new submodule), but where is the final git submodule update --init after the checkout?

musl linux is cloning, and then fetching this PR (which has a new submodule), but where is the final git submodule update --init after the checkout?

We didn't need it until this PR. I'd expect this to break downstream CI in places as well, but nothing we can do about that beyond a clear error message.

Also, sigh:

        # using git commands to clone because versioneer doesn't work when
        # actions/checkout is used for the clone step in a container

how things go in circles ...

We didn't need it until this PR.

I think the problem here is we are adding a new submodule in the PR. Perhaps the previous times we added a submodule (for svml, x86-simd-sort) we didn't check/care that fetching the submodule failed.

I think the problem here is we are adding a new submodule in the PR. Perhaps the previous times we added a submodule (for svml, x86-simd-sort) we didn't check/care that fetching the submodule failed.

Indeed - that's part of the tradeoff of git submodule vs. inclusion of sources. I think we should simply accept it though, it's part of the deal.

This looks ready now, all CI seems happy (the one TravisCI failure is the regular ppc64le job abort). @mattip if this looks good to you, how about we merge this and then I'll try and get the PR to enable SIMD support merge today too? That plus final tweaks to versioneer removal should get us to where we can do a first 1.26.0 pre-release.

Thanks @rgommers

@charris I suggest to wait with backporting anything until we've got gh-23096 in too. It's possible a few tweaks are still required, we'll see.

Grr, turns out Windows is problematic, prepending to os.environ['PATH'] does not work in getting the meson executable to be picked up. Seems to be a common problem with no great answer:

• https://stackoverflow.com/questions/30006722/os-environ-not-setting-environment-variables
• https://stackoverflow.com/questions/58700842/how-to-add-path-to-os-environpath-for-python-in-windows-10
• https://stackoverflow.com/questions/488366/how-do-i-make-environment-variable-changes-stick-in-python

Maybe it also has to do with the checkout being on D: and all path directories including the Python console_scripts one on C:. Some debug printing in CI of os.environ['PATH']:

 D:\a\numpy\numpy\vendored-meson\entrypoint;C:\Users\runneradmin\AppData\Local\Temp\pip-build-env-jxw1inia\overlay\Scripts;C:\Users\runneradmin\AppData\Local\Temp\pip-build-env-jxw1inia\normal\Scripts;C:\Program Files\PowerShell\7;C:\Users\runneradmin\AppData\Roaming\Python\Python311\Scripts;C:\hostedtoolcache\windows\Python\3.11.4\x64\Scripts;C:\hostedtoolcache\windows\Python\3.11.4\x64;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\cf-cli;C:\Program Files (x86)\NSIS\;C:\tools\zstd;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\2.11.1\x64;C:\cabal\bin;C:\\ghcup\bin;C:\Program Files\dotnet;C:\mysql\bin;C:\Program Files\R\R-4.3.1\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\npm\prefix;C:\hostedtoolcache\windows\go\1.20.7\x64\bin;C:\hostedtoolcache\windows\Python\3.7.9\x64\Scripts;C:\hostedtoolcache\windows\Python\3.7.9\x64;C:\hostedtoolcache\windows\Ruby\2.5.9\x64\bin;C:\Program Files\OpenSSL\bin;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.382-5\x64\bin;C:\Program Files\ImageMagick-7.1.1-Q16-HDRI;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\Program Files\Eclipse Foundation\jdk-8.0.302.8-hotspot\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\Chocolatey\bin;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\160\DTS\Binn\;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.7\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\nodejs\;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GitHub CLI\;c:\tools\php;C:\Program Files (x86)\sbt\bin;C:\SeleniumWebDrivers\ChromeDriver\;C:\SeleniumWebDrivers\EdgeDriver\;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files (x86)\Microsoft BizTalk Server\;C:\Program Files\LLVM\bin;C:\Users\runneradmin\.dotnet\tools;C:\Users\runneradmin\.cargo\bin;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps

So the right directory is there, but in the subprocess.run calls that invoke meson, they don't pick up numpy\vendored-meson\entrypoint/meson.

If anyone has successfully done this before on Windows, I'm all ears as to how you did it.

I spent ~ half a day debugging on CI and investigating the problem on Windows. It seems impossible to do this via PATH manipulation. The meson script with the executable bit set is not running, even when you put it right next to the __init__.py of the in-tree build backend or use the full path to it. On the other hand python /path/to/entrypoint/meson runs perfectly fine. This is very simple to do with a fork of meson-python, which I had initially.

Unless someone (@eli-schwartz or @mattip maybe?) has an answer to this, I'll go back to a modified meson-python and will include it as a git submodule too.

Oh... that is probably because of the interesting rules for executing scripts on Windows, which is pretty conditional on which APIs you use to start the process. It works fine with python path/to/entrypoint because of course, python is a real PE .exe file. Wheel installers such as pip solve this by using distlib's launcher executable, which is a real PE executable that then launches the script. While in theory this too could be vendored, it sounds like too much work mostly because how do you make sure it works on both 32-bit and 64-bit Windows?

I guess you could add upstream meson-python support for setting $MESON similarly to $NINJA, then very quickly release a new meson-python point release.

I guess you could add upstream meson-python support for setting $MESON similarly to $NINJA, then very quickly release a new meson-python point release.

Yes, I think I'd like to add support for $MESON, which is a good idea in general. But at a gentler pace; if we get that before the final 1.26.0 release then that should be fine.

Some debug printing in CI

Which CI run?

Which CI run?

There's ~10 failed builds with different invocations at https://github.com/rgommers/numpy/actions. I'd advise not digging into those, because they won't tell you much beyond "yes the paths were right, and no the meson executable never runs".

My current plan is:

1. Fork meson-python and add it as a git submodule in a similar way as done for meson in this PR
2. Get BLD, SIMD: The meson CPU dispatcher implementation  #23096 merged
3. Backport to 1.26.x for a pre-release
4. Add $MESON support for meson-python as Eli suggested
5. Do a meson-python release, then undo the meson-python vendoring

Assuming you are in a venv (so sys.executable is in scripts), maybe copy the meson.exe from python -c "import os, sys; print(os.path.dirname(sys.executable)) to vendored-meson\entrypoint ?

I've tried multiple variations like that already. And in venv or not doesn't matter (and we can't assume anything about that anyway, it should work robustly no matter the type of env).

It's very much not worth the fuss. Do note however that the meson.exe files are different -- that PE executable is created by taking the base launcher executable vendored in distlib, and appending a zipapp with a path/to/python.exe shebang and a __main__.py which is a renamed script entrypoint (usually does the importlib.metadata.distribution(XXX).entry_points dance). It doesn't contain the special sys.path munging that meson's git repository wrapper script has.

one option would be to cd into vendored-meson/meson and do pip install .

That's a no no, we can't just go install a meson package into the active env that the user did not ask for. We cannot make any permanent changes to the build env.

gh-24365 was actually the correct and pragmatic approach, modulo that I should have used git submodules there.

pragmatic approach

It doesn't need to be beautiful as long as it gets the job done :)

Do note however that the meson.exe files are different

That's a point of complexity for the $MESON idea probably, right? I wouldn't want to deal with that, but rather have a rule that of $MESON contains a name ending in .py, it'll be run by meson-python with sys.executable prepended - that should be much easier and more robust.

Right, a .py script is the logical way to do this. It should be safely assumed that if the entrypoint contains an explicit .py then it is not a $PATH installed tool expecting to import mesonbuild.mesonmain:main() from site-packages, and rather it's a setup script that sets its own path up. This also makes sure that things work on e.g. FreeBSD, where #!/usr/bin/env python3 does not work because some clever fellows decided that it is "unnecessary" for software installed via the BSD ports tree and containing /usr/local/bin/python3.9 shebangs or whatever version of python they have in the /usr/local hierarchy at any given time.

(Apparently there's an optional package containing the "python3" symlink for people that really really want it, but you need to know you need it.)

The other possible approach is documenting that the $MESON variable is handled like $CC -- as a space-separated list of arguments e.g. python.exe vendored-meson\\entrypoint\\meson.py. But I don't think there's any real advantage there.

Thanks. Agreed, both of those should do the job. I'll open the feature request soon and will try to get this into the next version.

(Apparently there's an optional package containing the "python3" symlink for people that really really want it, but you need to know you need it

🤦🏼