Bug 265176 - lang/python3* distributes ensurepip, etc, which can break devel/py-pip and devel/py-setuptools
Summary: lang/python3* distributes ensurepip, etc, which can break devel/py-pip and de...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-python (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-12 17:00 UTC by Enji Cooper
Modified: 2022-07-12 19:29 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (python)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enji Cooper freebsd_committer freebsd_triage 2022-07-12 17:00:49 UTC
The python interpreter provides setuptools/pip along with the interpreter for bootstrapping the pip and setuptools packages: https://docs.python.org/3/library/ensurepip.html .

Using ensurepip from python is wrought with headaches though; using it can break systems in the following scenarios:

1. lang/python310 distributes pip/setuptools version X, whereas devel/py-pip requires pip/setuptools version Y. If version X > version Y and `python3.10 ensurepip --upgrade` is run by root, ensurepip will upgrade the system package versions of pip/setuptools, resulting in files being installed to the system site-packages which no longer match the devel/py-pip@py310 installed files.
2. The root user has a non-permissive umask (007). If `python3.10 -m ensurepip --upgrade` is run as root, the packages installed will not be accessible to unprivileged users (depending on group ownership), rendering packages which rely on setuptools (and the libraries it provides) unusable to unprivileged users.

ensurepip should be completely removed from lang/python3* and instead provided as a separate standalone package, e.g., devel/py-ensurepip, OR (better yet) just removed from lang/python3*, requiring the end-user to rely on devel/py-pip and devel/py-setuptools packages explicitly. The latter option is how other *nix distributions (CentOS Linux, Debian Linux) have dealt with this potential pitfall.

More discussion about this can be found in PEP-453: https://peps.python.org/pep-0453/ .