Does not work with a shared libpython3.so on run-time search path

[wimglenn]

I'm using the CPython configure flags --enable-shared with an rpath interpolation (LDFLAGS). Linux platform (RHEL 8.3).

The interpreter's stdlib venv works just fine, but poetry installer doesn't like something about that config

$ readelf -d /usr/local/bin/python3.11 | grep rpath
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib]
$ ldd /usr/local/bin/python3.11 | grep libpython
	libpython3.11.so.1.0 => /usr/local/bin/../lib/libpython3.11.so.1.0 (0x00007ffff7632000)
$ curl -sSL https://install.python-poetry.org | /usr/local/bin/python3.11 -
Retrieving Poetry metadata

# Welcome to Poetry!

This will download and install the latest version of Poetry,
a dependency and package manager for Python.

It will add the `poetry` command to Poetry's bin directory, located at:

/home/wglenn/.local/bin

You can uninstall at any time by executing this script with the --uninstall option,
and these changes will be reverted.

Installing Poetry (1.2.2): An error occurred. Removing partial environment.
Poetry installation failed.
See /home/wglenn/git/python/poetry-installer-error-t8owbf6b.log for error logs.

The log:

$ cat /home/wglenn/git/python/poetry-installer-error-t8owbf6b.log
/home/wglenn/.local/share/pypoetry/venv/bin/python3.11: error while loading shared libraries: libpython3.11.so.1.0: cannot open shared object file: No such file or directory

Traceback:

  File "<stdin>", line 919, in main
  File "<stdin>", line 552, in run

[neersighted]

Likely another problem with using --copies with the virtual environment.

What does it look like when you create a virtual environment with --copies? e.g.

$ mypython -m venv --copies testenv
$ testenv/bin/python

[wimglenn]

You are right. I get:

Error: Command '['/path/to/testenv/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 127.

[neersighted]

Hmm, okay, so this is the same root cause #24, but with differing circumstances. Copies are quite useful as it prevents Poetry breaking when you upgrade your system Python interpreter, without duplicating shared objects... I'll have to consider whether we can preserve this feature and test for support in a robust/maintainable way, or if we just have to drop it and let users deal with the consequences of upgrading their Python.

[wimglenn]

Thanks for the info. For what it's worth, I would totally expect having to reinstall poetry if upgrading system interpreter.

[JamieMcKernanKaizen]

Yep, for anyone else stumbling on this issue - for me it was because I was using pyenv and I uninstalled the version of Python that I'd used to install poetry. So similar to @wimglenn, changing Python versions could require a re-install of poetry.