-
-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
Cannot build from source #18390
Comments
This is showing up on our CI too so is not an issue unique to you. Note before working on your new feature it is worth proposing it on the mailing list first so as to not waste effort. |
I cannot reproduce locally on two separate Linux boxes, and the failure is even showing up on ARM flavors of Linux and MacOS in CI per gh-18392, so it can't just be a compiler update on a single platform. |
I'm seeing this locally. I was going to try meson-python as well, but you tried that. |
I can build if I don't use Pythran. If I do use Pythran the meson log looks something like:
|
I also tried to use pythran on an easier example: def dprod(l0,l1):
"""WoW, generator expression, zip and sum."""
return sum(x * y for x, y in zip(l0, l1)) Trying to pythranise it (
Installed packages:
@serge-sans-paille, it looks like something upstream in Pythran/Pythran's dependencies may be causing this. Can you shine light on the situation? |
@andyfaff can you try |
Released April 29th, so that makes sense, also doesn't get bumped easily in my old virtualenvs, had to make a fresh one to repro and pull in new |
Rolling back to gast=0.5.3 gets me:
(Not sure if that's what I'm supposed to see from a pythran call, but at least it's not the other message). |
For SciPy proper, I can definitely build from source with |
This cost me an hour of fiddling around last night, couldn't understand why I couldn't build. |
Yeah, intermediate build deps are a bit more annoying to intercept/pin as well. I'm not sure if we'll get a yank for that release, just replace it with a new/fixed one soon, or if we should i.e., manually pin |
Or turn off Pythran parts maybe through |
Better to pin gast IMO than turn off pythran completely. |
We don't have much pythran presence anyways and the parts rely on Pythran have also Cython fallbacks in case you have performance in mind. |
There's a fair few places that we'd have to modify to make a pin like that, and turning off Pythran isn't necessarily that easy either. I'd hope that the gast release would get yanked pretty quickly. @serge-sans-paille is the maintainer for both gast and pythran, so would be able to do that. |
If I get time we could put necessary workarounds into e.g. |
Looks like there's an upstream |
So pythran 0.13.0 got released, which fixed the compatibility with gast 0.5.4, but seems to break something else:
I'm seeing this in musllinux_amd64_test and the "Windows tests / cp310 (meson) fast" job. |
@h-vetinari can you report that upstream? |
Already did (currently only as a comment in serge-sans-paille/pythran#2100; can be turned into an issue if I didn't overlook something obvious). |
An alternative to unbreak current (already released as of now) pythran+gast would be to move to C++17. We've been ready for this for a while. Of course, unbreaking CI should be uncoupled from such a decision, but it might be independently worthwhile and uncontroversial, hence why I'm mentioning it. |
I have a sinking feeling that this consideration has become out of date; judging from
|
Oh dear, this is a bit frustrating. Isn't it also strange that we're depending on |
Pytrhan maintainer here: Yeah, it's frustrating, but I don't want to start maintaining different branches / releases, so I'm just releasing new version of Pythran. A bit unsound from a theoretical point of view, but that's the best I have to offer given my bandwidth :-) |
@serge-sans-paille there is a problem with that: pythran 0.12.1 has the requirement I can offer to help with maintaining bugfix releases and dependency specifiers if that helps with the bandwidth issue. This is important for us though - we carefully put upper bounds on |
Got it, I'll do a pythran 0.12.1 branch with the gast patch, that seems to be
the easiest way.
|
@rgommers : first attempt in https://github.com/serge-sans-paille/pythran/tree/release/0.12.2. I can tag it and release it on PyPI if it matches scipy's need. Just to clarify the problem : I did a patch release of gast, but this had a side effect of introducing a new global object that matches the dynamic condition |
Thanks! The version specifier should be |
@rgommers like this? (I guess you meant |
oops, yes indeed. |
release 0.12.2 tagged on github and pushed on PyPI. If I understand correctly this should fix scipy builds without needing to change anything in scipy code, correct? |
Indeed. I'll restart a CI job to verify right now, but everything should be fixed. Thanks a lot! |
That being said, Pythran 0.13.1 has a lot of performance improvement, you should give it a chance ;-) |
Definitely. We are automatically using that on SciPy |
Indeed seems all fixed, closing. Thanks everyone for helping debug this! |
Want to build from source to work on adding a missing distribution (Landau distribution). Following the steps from here. Using the pip+venv workflow. Already cloned the repo and created the virtual environment, run
python -m pip install numpy pytest cython pythran pybind11 meson ninja pydevtool rich-click
successfully. I am getting an error when runningpython3 dev.py build
, specificallymeson.build:1:0: ERROR: Cython compiler 'cython' cannot compile programs
. If I look into the log I find:How can I fix this to build the development version of scipy?
OS: Ubuntu 22.04.
Python: 3.10.6
The text was updated successfully, but these errors were encountered: