-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
bpo-1294959: Add --with-platlibdir to configure #18381
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
Conversation
Fedora is maintaining a downstream patch for years in the different python packages: https://src.fedoraproject.org/rpms/python3/blob/master/f/00102-lib64.patch This PR is not this patch, it's a rewrite based on the Fedora: we made the library name configurable. This PR doesn't change the default which remains "lib". It only adds an opt-in option for Linux vendors like Fedora and OpenSUSE who already change this directory. I'm not sure about Debian/Ubuntu (I have to check). Previous attempts to implement https://bugs.python.org/issue1294959:
There is also https://bugs.python.org/issue34032 which should be marked as a duplicate. |
test_embed is failing. I have to investigate to understand why, so I marked the PR as a WIP. Note: I excluded the setup.py change of the Fedora change from this PR, it doesn't seem to be directly related to this PR. |
Hum, once this PR wil lbe merged, I will work on a separated PR for setup.py. |
I compared this PR with PR #3698 written by Jan Matějek for OpenSUSE. They look very similar. The main differences are that:
I don't know how it's used. In practice, I only have
All differences:
|
I guess that the intent was to be able to co-install i686 (32-bit) and x86-64 (64-bit) flavors of Python 3 without having conflicts on paths. For example, python3-libs.i686 installs os.py into /usr/lib/python3.7/os.py, whereas python3-libs.x86_64 installs os.py into /usr/lib64/python3.7/os.py. On Fedora 31, I can co-install python3.i686 and python3-libs.i686, whereas python3.x86_64 and python3-libs.x86_64 are already installed. But I failed to run the 32-bit version of /usr/bin/python3.7. This file is provided by python3.i686 and python3.x86_64, but it seems like the 64-bit flavor won. |
@stratakis's PR #11755 is very similar to @matejcik's PR #3698. He even explained it: "This PR is based on #3698 rebased on top of master and the NEWS entries tidied up a bit. I haven't tested it yet as of recently thus the WIP in the title." |
On SUSE, the stdlib is also in /usr/lib64. Example: /usr/lib64/python3.7/os.py |
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA). Recognized GitHub usernameWe couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames: This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for the contribution, we look forward to reviewing it! |
Even with (generated, so too long) configure command:
I get Used tarball is When checking the generated LIBPL= $(prefix)//python3.9/config-$(VERSION)$(ABIFLAGS)-x86_64-linux-gnu which seems to me obviously wrong. I would think it should be LIBPL= $(LIBDIR)/python3.9/config-$(VERSION)$(ABIFLAGS)-x86_64-linux-gnu |
@vstinner OK, aside from the above problem with config-* subdir and bpo#39855, Python 3.9.0a3 builds correctly and all tests pass. +1 from me. |
Oops. That's a stupid typo, it's now fixed. Well spotted, thanks! |
Output of
|
Ok ok, we reached the point where the most important question became... the option name :-D There are several choices:
@brettcannon @encukou @stratakis @]mcepl: What's your call on this very important question? :-D Not considered:
About the need for adding a new sys attribute. SuSE doesn't add a sys attribute, instead it imports sysconfig in site which has a negative impact on Python startup performance. I chose to add an attribute to sys to avoid that. |
@mcepl: "Output of lib64_tests.py reports one failure: (...) AssertionError: '/home/abuild/rpmbuild/SOURCES' != '/usr/lib64/python39.zip'" Well, it's really hard to test sys.path. You can ignore this error. It seems like something injected SOURCES in sys.path which wasn't expected by the test. At least, other tests passed which is great! |
Since you explicitly asked for bikeshedding:
I'd go for |
I concur with Petr. I really like the |
👍 to Petr's suggestion |
I updated the PR to use I completed the list of authors::
https://bugs.python.org/issue1294959 has a long history, and these 3 developers wrote earlier patche and pull requests. We all collaborated somehow.
I dislike the |
From my perspective the PR looks good to me. |
Changes:
|
+1 from me. It builds without any problem. |
Add --with-platlibdir option to the configure script: name of the platform-specific library directory, stored in the new sys.platlitdir attribute. It is used to build the path of platform-specific dynamic libraries and the path of the standard library. It is equal to "lib" on most platforms. On Fedora and SuSE, it is equal to "lib64" on 64-bit systems. Co-Authored-By: Jan Matějek <[email protected]> Co-Authored-By: Matěj Cepl <[email protected]> Co-Authored-By: Charalampos Stratakis <[email protected]>
I updated the PR to complete/adjust the documentation. It works as expected. I tested my PR with:
Output:
|
I created https://src.fedoraproject.org/rpms/python39/pull-request/31 to test this PR on the python39 RPM package for Fedora 31 (Stable). |
The scratch build (temporary package for testing) completed successfully on x86-64: the patch applies and built Python uses /usr/lib64 as expected. I tested manually lib64_tests-3.py of https://bugs.python.org/issue1294959: paths are unchanged with this PR. It means that #18381 works as expected. |
I addressed Brett's review ("Probably need to expand the docs a bit as well as a suggestion on how to simplify some code.")
|
Add --with-platlibdir option to configure to choose where
platform-specific and standard library files are installed
(default: 'lib'). It is used on Fedora and SuSE to use /usr/lib64
instead of /usr/lib on 64-bit systems.
Add sys.platlibdir attribute.
Co-Authored-By: Jan Matějek [email protected]
Co-Authored-By: Matěj Cepl [email protected]
Co-Authored-By: Charalampos Stratakis [email protected]
https://bugs.python.org/issue1294959