Defining a support policy on overlapping installations

Core Development
1

During the downstream adoption of PEP 739, where we added a build-details.json file to the standard library directory, some issues came up regarding it conflicting on multiple installations.

We never defined a policy on what shape of installations we support, or what kind of configurations we support installed in parallel.

To make things simple, for now, I want to ask the following questions.

  1. Do we support installing debug and non-debug builds under the same prefix, libdir, and libdir subdirectory?

  2. Do we support installing regular and free-threaded builds under the same prefix, libdir, and libdir subdirectory? What about future different ABIs?

  3. Do we support installing the same build, but of multiple architectures under the same prefix, libdir?

  4. Are there any other considerations we should take into account?

These questions are in regard to shipping Python to users, not local installations for development.

Additionally, please consider the following:

  • Currently, the PyPI ecosystem is only prepared for same-ABI same-platform packages
    • Debug builds are the outlier here – they able to load extension modules for the same non-debug ABI.
    • Cases 2) and 3) currently fundamentally break the PyPI ecosystem
    • Currently, installations using the official Windows installer, but only because of a technical limitation with Windows installers, which is problematic
  • Even though installations might have the same prefix, libdir, and libdir subdirectory, currently, they all still need to have their own set of headers (this is something we could change, but is the current status-quo)

There’s probably something I missed, but I think this is enough to get the conversation started.

That said, whatever we decide, I acknowledge it would be difficult to enforce the policy, but I still believe it is something we should do. This sets expectations for downstream distributors, and is something we can reference when we receive bug reports from users due to the policy not being followed. With this, I am not saying we simply deny support to users, IMO we would consider situations on a case-by-case basis.

1 Like
2

Here are my personal opinions.

I would greatly prefer to keep things as simple as possible and define that installations with different platforms and different ABI flags MUST NOT conflict with each other when sharing the same prefix and all other installation directories. This makes things much simpler to define, and makes everything consistent across the board.

EDIT: I realized that part was implied, and should not be part of the wording used for the definition.

My answer above would mean I would answer no to this question. This brings the question of the value of the use-case of sharing site-packages between debug and regular builds, which I think is valid. However, we already have officially supported mechanisms that make this possible in the site module, such as sitecustomize, for eg. that distributors can employ to achieve this — I don’t think it is something that needs to be supported at the installation level.

To clarify, I am proposing that the regular builds use /usr/lib/python3.15, and debug builds use /usr/lib/python3.15d, just like they do for the headers.

Distributions, such as Fedora, which provide the functionality described in the use-case above, could still implement it via a different mechanism.

Per my suggestion above, no. Each ABI gets its own install locations.

This presents the same issues as the multiple ABIs, so my opinion is no.

2 Likes