gh-133951: Remove lib64->lib symlink in venv creation

[Cycloctane]

venv creates a lib64->lib symlink on posix platforms (except osx) to make purelib and platlib always share the same directory in all dists (#65396). This can cause problems on filesystems without symlink support. It is also not necessary anymore because venv now creates lib paths in venv directory based on sysconfig. Others should also use sysconfig to get the correct lib paths.

• Issue: creating venv Python3.13 on CIFS mounted drive fails ENODATA #133951

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[picnixz]

More generally, could it cause issues with platforms that are configured with --with-platlibdir=lib64? On OpenSUSE I need to explicitly specify this when doing ./configure, otherwise Python won't be correctly installed.

It is also not necessary anymore because venv now creates lib paths in venv directory based on sysconfig.

Is there a possibility that this could somehow conflict with legacy venvs? or with some weird sysconfig? If this is causing issues on platforms without symlink support why not just checking if that platform supports symlinks and, if not, do nothing?

[Cycloctane]

could it cause issues with platforms that are configured with --with-platlibdir=lib64?

The difference on these platforms is that platlib and purelib modules will be installed into separated directory (lib64/ and lib/) as defined in posix_venv installation scheme. This is also virtualenv's current behavior.

Is there a possibility that this could somehow conflict with legacy venvs?

I think this only affects venv creation. Legacy venvs should still be able to run.

If this is causing issues on platforms without symlink support why not just checking if that platform supports symlinks and, if not, do nothing?

In my understanding this symlink is not needed in anyway. Other paths created by venv are all looked up from venv scheme sysconfig except this symlink which is hard-coded and created even unnecessary. So I remove it for consistency.

[FFY00]

Thanks for the PR!

There's a possibility it would break user code when users are hardcoding the path, or not using the venv scheme. Though, the code is already fundamentally broken in both those situations, so I agree with this change.

That said, if possible, I'd like @vsajip to also have a look before merging.

@Cycloctane, please ping me in 1~2 weeks if the PR hasn't moved.

[vsajip]

I'm OK with this change, though of course there might be a backwards compatibility issue for someone; but I guess we can deal with it if and when it happens.

[Cycloctane]

please ping me in 1~2 weeks if the PR hasn't moved.

@FFY00 :)

[FFY00]

@Cycloctane, sorry for the delay!