cpython interaction issue (undefined symbol: _PyModule_Add) which seems to occur with poetry on python=3.11.0

[femtomc]

Hello! Recently my CI/CD pipeline (with poetry -- installed via https://github.com/snok/install-poetry) has been broken suddenly. I tracked the problem to this issue -- which seems to involve some interaction with poetry:

python/cpython#108525

As far as I can tell, there's no open issue investigating this.

[dimbleby]

You haven't said what you think this project should be doing: but I expect a merge request fixing whatever it is that you think is broken would be welcome

[femtomc]

I have no idea what I think this project should be doing, nor do I have the expertise to submit a merge request to fix it. Anecdotally, my read of the original issue thread is that there's some sort of ABI interaction (and possibly, cpython is the source).

It seems that updating Python version to 3.11.5 fixes the problem with latest poetry -- (my CI was running on 3.11.0).

If anything, it seems useful to have a issue which tags this problem for other users -- as I had to dig deep in my CI logs (and then, Googling to find the above issue in cpython).

Does that sound fair?

[dimbleby]

if you can provide a way to reproduce a problem and a reason to think that it's a poetry bug, then raising an issue is the right thing to do.

However you haven't done either of those - or even said what the problem is that you are trying to report. I don't see anything useful that anyone can do with this.

[femtomc]

Sure, I can attempt to put together a reproducer.

Separately — I’m just trying to be helpful by pointing out something I noticed while developing a package, and finding a thread where several people seemed to note that the same issue stemmed from something in poetry — all seemingly users of poetry.

After a search for similar issues, I decided to open one assuming it would be useful for someone to know about outside of the cpython repo (perhaps, say, in poetry — a common use point for responders in the linked issue)

You are of course allowed to respond in whatever way you choose — but I’m a little surprised that your response is “fix it yourself, and it’s not useful to know about this” irrespective of whether I can provide a reproducer.

Why would I want to contribute a PR to a package when a maintainer responds in that sort of way?

[femtomc]

Here's a simple reproducer (as a repo, with a CI job): https://github.com/femtomc/8452-minimal-repro/actions/runs/6242454039/job/16946411608

I don't believe that the other actions are causing the issue e.g. https://github.com/snok/install-poetry/blob/main/main.sh (for instance) is using the officially recommended way to install poetry (via curl).

I've created two jobs -- one with python=3.11.0 and one with python=3.11.5. One passes, and one fails.

[dimbleby]

I'm sorry that you haven't enjoyed getting there: but we are now in an infinitely more useful place than where we started!

Thing that come to mind

• I'm far from convinced that this is anything to do with the linked cpython issue: that is talking specifically about ssl, which seems not to be involved at all in your repro
• the use of nox-poetry makes this repro quite non-minimal. I for one have no idea what nox-poetry is doing here, or whether it's something that is reasonable from poetry's point of view
  • Are you able to reproduce the problem using poetry directly?
• eg you have nox-poetry in a python 3.9 environment which complicates matters

2023-09-20T00:37:05.1914053Z   Error output:
2023-09-20T00:37:05.1914321Z   Traceback (most recent call last):
2023-09-20T00:37:05.1920844Z     File "<stdin>", line 18, in <module>
2023-09-20T00:37:05.1921339Z     File "<frozen importlib._bootstrap_external>", line 940, in exec_module
2023-09-20T00:37:05.1921841Z     File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
2023-09-20T00:37:05.1922517Z     File "/home/runner/.local/venv/lib/python3.9/site-packages/packaging/tags.py", line 7, in <module>
2023-09-20T00:37:05.1922890Z       import subprocess
2023-09-20T00:37:05.1923298Z     File "/opt/hostedtoolcache/Python/3.11.5/x64/lib/python3.11/subprocess.py", line 119, in <module>
2023-09-20T00:37:05.1923658Z       import selectors
2023-09-20T00:37:05.1924047Z     File "/opt/hostedtoolcache/Python/3.11.5/x64/lib/python3.11/selectors.py", line 11, in <module>
2023-09-20T00:37:05.1924386Z       import math
2023-09-20T00:37:05.1925340Z   ImportError: /opt/hostedtoolcache/Python/3.11.5/x64/lib/python3.11/lib-dynload/math.cpython-311-x86_64-linux-gnu.so: undefined symbol: _PyModule_Add

this stack includes both python3.9 and python3.11, which seems unlikely to be what's wanted

I've never used nox-poetry and have no idea what requirements it has - or ought to declare - on the relationship between the nox / poetry / nox-poetry environments. I think that to convincingly make this a poetry bug the next step is to eliminate that complication from the repro. (You also could maybe ask the nox-poetry people for comment)

Edit: I further notice that even in the passing case, nox is warning Warning: poetry is not installed into the virtualenv, it is located at /home/runner/.local/bin/poetry. This might cause issues! Pass external=True into run() to silence this message.. While I don't know nox well enough to call this a smoking gun, it certainly is consistent with a theory that says nox-poetry is introducing confusion.

[dimbleby]

I notice that stack also includes python 3.11.5, even though it's from the intended python 3.11.0 repro.

Perhaps what you are discovering here is actually some confusion in github's caching of tools in CI pipelines.

[femtomc]

I will retry and remove nox-poetry, thanks for noticing that.

[lazka]

Drive by comment: The _PyModule_Add symbol was added in 3.11.5 and is also used by some of the included extension modules in CPython. Afair this is the first time such a change happened with a bugfix release in the past years. So this exposes broken environments where libpython and the stdlib of different cpython patch versions are mixed for some reason.

[abn]

Root cause is as identified by @lazka. This is not a Poetry issue, but rather an issue with the system environment setup. The project at https://github.com/snok/install-poetry is not affiliated with nor maintained by the Poetry project maintainers.

Closing this issue as there is no Poetry action here.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.