Use the "venv" scheme if available to obtain prefixed lib paths by dnicolodi · Pull Request #11598 · pypa/pip (original) (raw)

dnicolodi

get_prefixed_libs() computes the Python path for libraries in a pip isolation environment. Python 3.11 introduced the "venv" path scheme to be used in these cases. Use it if available.

This solves a bug on Homebrew's Python 3.10 and later where the default paths scheme when Python is invoked outside a virtual environment is "osx_framework_library" and does not relative to the "{base}" or "{platbase}" variables.

Fixes #11539.

dnicolodi added a commit to dnicolodi/meson-python that referenced this pull request

Nov 16, 2022

@dnicolodi

dnicolodi added a commit to dnicolodi/meson-python that referenced this pull request

Nov 16, 2022

@dnicolodi

uranusjr

Comment on lines 216 to 222

def get_prefixed_libs(prefix: str) -> typing.Tuple[str, str]:
paths = sysconfig.get_paths(vars={"base": prefix, "platbase": prefix})
vars = {"base": prefix, "platbase": prefix}
if "venv" in sysconfig.get_scheme_names():
paths = sysconfig.get_paths(vars=vars, scheme="venv")
else:
paths = sysconfig.get_paths(vars=vars)
return (paths["purelib"], paths["platlib"])

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this function is only used for creating isolated environments, let’s rename it to better describe what it does. This avoids needing to think about why this always sets venv even when pip is not running in a virtual environment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought prefixed in the name carried this message. Do you have a better name in mind?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just get_isolated_environment_lib_paths?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds descriptive enough. Should I change the argument name to environment then?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prefix is probably fine (it is the environment’s path prefix after all)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed that the function name is meant to reflect the name of a similar function in distutils. It is also called from a function with the same name in another module, see

def get_prefixed_libs(prefix: str) -> List[str]:
"""Return the lib locations under ``prefix``."""
new_pure, new_plat = _sysconfig.get_prefixed_libs(prefix)
if _USE_SYSCONFIG:
return _deduplicated(new_pure, new_plat)

Should we still change just this one?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, change them all.

FFY00 pushed a commit to mesonbuild/meson-python that referenced this pull request

Nov 16, 2022

@dnicolodi @FFY00

@dnicolodi

get_prefixed_libs() computes the Python path for libraries in a pip isolation environment. Python 3.11 introduced the "venv" path scheme to be used in these cases. Use it if available.

This solves a bug on Homebrew's Python 3.10 and later where the default paths scheme when Python is invoked outside a virtual environment is "osx_framework_library" and does not relative to the "{base}" or "{platbase}" variables.

Fixes pypa#11539.

@dnicolodi

Since this function is only used for creating isolated environments, rename it to better describe what it does. This avoids needing to think about why the implementation uses the "venv" paths scheme even when pip is not running in a virtual environment.

uranusjr

@wimglenn

pradyunsg

@pradyunsg

I've triggered a CI re-run for some flakiness.

@dnicolodi

All green now. Can this be merged or there is anything left to do?

dnicolodi added a commit to dnicolodi/pip that referenced this pull request

Nov 27, 2022

@dnicolodi

The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes.

However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293.

The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.

dnicolodi added a commit to dnicolodi/pip that referenced this pull request

Nov 27, 2022

@dnicolodi

The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes.

However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293.

The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.

dnicolodi added a commit to dnicolodi/pip that referenced this pull request

Nov 27, 2022

@dnicolodi

The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes.

However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293.

The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.

dnicolodi added a commit to dnicolodi/pip that referenced this pull request

Nov 27, 2022

@dnicolodi

The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes.

However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293.

The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.

dnicolodi added a commit to dnicolodi/pip that referenced this pull request

Nov 27, 2022

@dnicolodi

The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes.

However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293.

The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.

dnicolodi added a commit to dnicolodi/pip that referenced this pull request

Nov 27, 2022

@dnicolodi

The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes.

However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293.

The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.

dnicolodi added a commit to dnicolodi/pip that referenced this pull request

Nov 29, 2022

@dnicolodi

The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes.

However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293.

The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.

dnicolodi added a commit to dnicolodi/pip that referenced this pull request

Nov 29, 2022

@dnicolodi

The scripts path was looked up passing explicitly the scheme to be used using "nt" on Windows and "posix_prefix" everywhere else. However, when the isolated build environment is created, packages are installed using the default scheme for the platform. On most platforms this works because normally "nt" and "posix_prefix" are the default schemes.

However, Debian customizes sysconfig to use a "posix_local" scheme by default and under this scheme the scripts path does not match the one of the "posix_prefix" scheme. This results in scripts installed as part of the build dependencies not to be found during the build, as reported here mesonbuild/meson-python#109 and here https://bugs.debian.org/1019293.

The problem can be solved omitting to specify a scheme when looking up the scripts path. To future proof the path lookup, use the "venv" scheme if available as done in pypa#11598. For uniformity use similar functions as used to lookup the library paths.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators

Dec 4, 2022