Ned Deily added the comment:
Here's a patch for review. It implements:
* a new configure option:
--with(out)-ensurepip=[=upgrade]
"install" or "upgrade" using bundled pip
* a new makefile macro ENSUREPIP that can be supplied to a "make install" or
"make altinstall" target to override the configure option:
make [alt]install ENSUREPIP=[install|upgrade|no]
While testing the above I've identified a number of issues. I haven't had time
to do more than a quick triage on most of them so the initial analyses may be
wrong.
Wheel installation issues:
1. Files, but not directories, from the pip/setuptools wheel were installed
with a different group id than when installed with pip from a source dist.
(This was comparing the current checked-in wheel file versus a normal sdist pip
install of pip, on OS X.) It appears that the files installed from wheels
ended up with the effective gid of the installing process, while those from
sdist files had the group id of the parent directory like other files installed
by make [alt]install (POSIX allows either behavior but pip should be
consistent).
2. It appears that .py files installed from wheels do not get compiled upon
installation (no __pycache__ or .pyc) whereas non-wheel pip installed .py files
do get compiled. (See also 7.)
3. The unversioned pip file name differs between wheel and non-wheel installs:
pip3.4 vs pip-3.4.
4. No unversioned version of easy_install is created for wheel installs, only
easy_install-3.4.
General pip issues:
5. Various ResourceWarnings about unclosed files and sockets were observed when
used with a debug python.
6. Perhaps more a Distutils issue but the files and directories created under
lib/python3.4/site-packages use the process default umask and thus may have
permissions different from the files installed for the standard library. The
latter get standard "install" permissions because the main Python setup.py
subclasses and overrides the default Distutils install_lib class to accomplish
this. Since the Makefile does not know exactly what files have been installed
by ensurepip, the install and altinstall targets could only guess at what files
need to be fixed up.
7. Other standard library .py files installed by "make [alt]install" are
compiled to both .pyc and .pyo versions.
ensurepip issue:
8. "make install" is a superset of "make altinstall" and one would expect the
results of (a) "make install" to be the same as (b) "make altinstall && make
install". However (b) results in "python -m ensurepip --altinstall --upgrade
&& python -m ensurepip --upgrade" which results in no unversioned pip files
being installed as the second call to pip does nothing:
Requirement already up-to-date: setuptools in
/py/dev/3x/root/uxd/lib/python3.4/site-packages
Requirement already up-to-date: pip in
/py/dev/3x/root/uxd/lib/python3.4/site-packages
Perhaps ensurepip module should also set "--ignore-installed" when calling pip?
Makefile:
9. I still need to create [alt]installunixtools links for pip* in
Mac/Makefile.in.
----------
nosy: +dstufft, loewis
stage: needs patch -> patch review
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19553>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
