Can't install due to "ninja: build stopped: subcommand failed." #249
Comments
|
Buried in some of what I had to trim, there is
which is what makes me ask whether something is missing. Or maybe I need to specifically install one of the sub packages first? |
|
Those files are auto-generated wrappers for the Fortran code so something is going awry before that step. I recently installed clawpack on a clean computer and did not have any issues so I think we are back to something weird about your environment. Unfortunately the real error is probably buried in the output you truncated. Most of it is output from the overly verbose auto-generated code mentioned before and not relevant. I would start looking for the word "error" in the output and see if you find anything that would be helpful. Note that there is one: but we are going to need more info than that to figure out what is going wrong. |
|
Hmm. "error" occurs 46 times in the output. You've accounted for 3. 8 more come from the FileNotFoundErrors. Each of those is preceded by a little section that reads like: which accounts for 4 more per each of those 8. We're at 43/46. The last 3 come from: "fail" occurs 10 times, once for each of the 8 FileNotFoundErrors (as above), and 2 in the postamble: I'm not sure that's giving us any more info, but maybe you can make heads or tails of it. What are some possible environment problems that might cause this not to play nice? I'm installing on two new Ubuntu machines. I went ahead and installed |
|
From the meson bug report (full build log was attached as LINK), I believe this is not a bug in meson. f2py_srcs = custom_target(
command: [f2py, ext_name],
input: ext_srcs,
output: [ext_name + 'module.c', ext_name + '-f2pywrappers.f'],
)Where ext_name is Only seems to emit a C file. In comparison, build rule 2: This is a problem because waaaaaaaaaaaaaay later on, this build rule fails: It assumes since the rule that is supposed to produce Unfortunately I believe f2py doesn't have an option to make it a fatal error if a wrapper is required but failed to be generated. |
|
Thanks for the analysis, Eli! @mandli, is my environment or version of f2py somehow to blame for this, or is this a build file issue? Would changing the version of meson or ninja I'm using help? I'm using the latest. |
|
What version of |
|
|
I have not actually seen the auto-generation fail before like this so I am a bit puzzled. As @eli-schwartz pointed I highly doubt that meson or ninja is to blame for this. Rather this sounds more likely to be a
Another thing to try as well is to just install the Fortran specific codes and test/troubleshoot those. That would ensure that there is not something wacky with your compiler, environment variables or basic python functionality. |
Fortran-specific: Then |
|
I think that version of numpy had a bug that affected Clawpack installation. It's likely that if you update numpy, this issue will go away. |
|
That is a really old version of numpy, actually. I upgraded to |
|
Looking at the error log, it seems that f2py creates wrappers for all but 7 of the Riemann solvers. Then when it tries to install those 7 Riemann solvers, it fails because the wrapper file doesn't exist. I can't see what is different about those specific solvers. They are:
|
@rgommers, I wonder if you know whether anything could be done about this? |
|
" From the comment above with the Lines 30 to 36 in 4c5990f numpy versions, that is a bug in numpy.f2py.
Please make sure with a clean build that the |
Then I run |
There is indeed such a failure mode: due to "build isolation", the versions of packages that are already installed is not relevant. That's what the If you add |
|
I'm starting to lose hope, guys. |
|
NumPy 1.26.4 is downloaded and there are indeed a number of missing files that cause your build to fail: So there should be a bug somewhere - I am having a closer look. I cannot reproduce the problem, at least on macOS I can build wheels just fine, and the |
|
The 7 |
|
Thanks for looking in to this more. When I run |
Is it not using the isolated env's |
|
I'm using the system's |
There is the temporary one that pip creates... |
|
If it's using f2py 1.21.5, and a relevant bug was fixed in 1.22.4, then do we just need to mandate it use a newer numpy? But didn't I already try that? I don't know which versions of f2py are packaged with which versions of numpy. I'm also slightly confused why no one can reproduce this bug. Has anyone tried it on Ubuntu? |
|
The temporary build venv's packages are as expected: This is the problem: If I check another CI job (from SciPy) on Ubuntu 22.04 that manually creates a venv on top of the system So somehow, for this version of Ubuntu and pip, the created venv does not get picked up correctly. Probably yet another way that Debian/Ubuntu's Python packaging is broken.
Yes, since Ubuntu 22.04 is the default CI image on GitHub Actions. You are doing something though that is very much not advised, which is mixing the system packages with user installs. This is broken in many ways, and this seems to be a new one. I don't think I have a CI job anywhere for this config.
numpy and f2py versions are always matching, so if In your setup, it wouldn't help to add |
That's not remotely a useful heuristic, since those are also using actions/setup-python rather than anything Debian/Ubuntu provides as packages. CI environments are unfortunately NOT an indicator of what works on an actual install. |
|
On my phone so can’t elaborate till tonight, but just to confirm: I do have two jobs that avoid the setup-python action and use Ubuntu’s system Python. I checked one of those.
…Sent from my iPhone
On 14/05/2024, at 8:43 AM, Eli Schwartz ***@***.***> wrote:
Yes, since Ubuntu 22.04 is the default CI image on GitHub Actions. You are doing something though that is very much not advised, which is mixing the system packages with user installs. This is broken in many ways, and this seems to be a new one. I don't think I have a CI job anywhere for this config.
That's not remotely a useful heuristic, since those are also using actions/setup-python rather than anything Debian/Ubuntu provides as packages. CI environments are unfortunately NOT an indicator of what works on an actual install.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
Ahha! 1.21.5! |
|
If I 🎉 |
|
Thanks for all the help on figuring this out! |
|
Great, glad that you got it to work @pavelkomarov. It looks like that's a bug in Debian's |
I've installed
meson --version1.4.0 andninja --version1.11.1.git.kitware.jobserver-1 (alsoninja --version1.10.1 on another machine with the same result), but now when I attemptpython3 -m pip install clawpack, I get a massively long ninja error I've never seen before. It's like all the types are failing to be defined. Are all the source files getting properly routed to where they need to go in the pip install?The text was updated successfully, but these errors were encountered: