This is similar to bpo-44860, but in the other direction:

    $ docker run -it --rm -h=p fedora:34 bash
    ...
    [root@p /]# yum install python3 -y
    ...
    [root@p /]# type python3
    python3 is hashed (/usr/bin/python3)
    [root@p /]# python3 -V
    Python 3.9.6
    [root@p /]# python3.9 -q
    >>> from distutils.command.install import install
    >>> from distutils.dist import Distribution
    >>> c = install(Distribution())
    >>> c.home = '/foo'
    >>> c.finalize_options()
    >>> c.install_platlib
    '/foo/lib64/python'
    >>> import sysconfig
    >>> sysconfig.get_path('platlib', 'posix_home', vars={'home': '/root'})
    '/foo/lib/python'

sysconfig’s scheme should use `{platlib}` instead of hardcoding 'lib'.

Note that on Python 3.10+ the platlib values from distutils and sysconfig do match (since the distutils scheme is automatically generated from sysconfig), but the issue remains; sysconfig’s scheme should likely include `{platlib}` (adding Victor and Miro to confirm this).

New changeset 4f88161f07538dfb24a43189fd59bf966cb40817 by Tzu-ping Chung in branch 'main':
bpo-45035: Make sysconfig posix_home depend on platlibdir (GH-28011)
https://github.com/python/cpython/commit/4f88161f07538dfb24a43189fd59bf966cb40817

Here, I'm not sure. What do people use --home for?

I don't think we need to match the `/usr/` scheme here. For Python software that's not part of a distro, I think just `lib/` is fine.

Hummmmm, I reviewed PR 38011 and the change made sense to me, but If you think we should reconsider PR 28011, please say so ASAP because the 3.10 backport is close to be merged

> I don't think we need to match the `/usr/` scheme here. For Python software that's not part of a distro, I think just `lib/` is fine.

I agree.

Miro, Petr, do you think then that we should revert PR 28011

The use case is a "personal stash of Python modules", described here: https://docs.python.org/3/install/#alternate-installation-the-home-scheme

We don't need the lib/lib64 distinction here.  I'd revert the 3.11 change and go with /lib/ only.

Ok, I am reverting PR 28011. Someone should check it again and decide what to do, but this won't enter 3.10

New changeset 97b754d4b46ad9dd63f68906484f805931578c81 by Pablo Galindo Salgado in branch 'main':
Revert "bpo-45035: Make sysconfig posix_home depend on platlibdir (GH-28011)" (GH-28201)
https://github.com/python/cpython/commit/97b754d4b46ad9dd63f68906484f805931578c81

See also the email on python-dev:
https://mail.python.org/archives/list/python-dev@python.org/thread/5UU6V2B3KBS4Z7OG5T7D6YQZASFNSBJM/

I wrote the PR 28204 to change the unix_home used by the distutils install command. Previous code:

        if sys.version_info >= (3, 9) and key == "platlib":
            # platlibdir is available since 3.9: bpo-1294959
            value = value.replace("/lib/", "/$platlibdir/")
        INSTALL_SCHEMES[main_key][key] = value

This code was added by:

commit 341e8a939aca6e9f59ffb0e6daee5888933694ed
Author: Lumír 'Frenzy' Balhar <frenzy.madness@gmail.com>
Date:   Wed Apr 14 17:12:34 2021 +0200

    bpo-41282: (PEP 632) Load install schemes from sysconfig (GH-24549)

Modifying the unix_home was not the intended behavior.

I'm doing the release of 3.10.0rc2 as we speak. Please, review this ASAP or otherwise this PR will not be backported to 3.10.0 and will have to wait to 3.10.1 as per the devguide.

AFAICS: this is a bug, but in deprecated code. Not worth fixing in 3.11, and definitely not worth fixing in a RC, and .

People should stop using distutils, and those who can't won't be happy with changes to it. Consider that existing distutils issues on bpo were already auto-closed.

(Sorry for the extra `and`; I hit Submit too soon)

Should we simply close the issue and leave distutils as it is?

Yes. This is a minor bug in the deprecated distutils module.