McSinyx/pip
1
1
Fork 0
mirror of https://github.com/pypa/pip synced 2023-12-13 21:30:23 +01:00
Code Issues Releases Activity

Merge pull request #5603 from pradyunsg/vendoring/update-readme

Browse source 
Update vendoring README file
This commit is contained in:
Pradyun Gedam 2018-07-20 09:40:29 +05:30 committed by GitHub
commit d6472d4c61
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
src/pip/_vendor/README.rst
View file

@ -22,9 +22,9 @@ Policy
Rationale
---------
Historically pip has not had any dependencies except for setuptools itself,
Historically pip has not had any dependencies except for ``setuptools`` itself,
choosing instead to implement any functionality it needed to prevent needing
a dependency. However, starting with pip 1.5 we began to replace code that was
a dependency. However, starting with pip 1.5, we began to replace code that was
implemented inside of pip with reusable libraries from PyPI. This brought the
typical benefits of reusing libraries instead of reinventing the wheel like
higher quality and more battle tested code, centralization of bug fixes
@ -43,7 +43,7 @@ way (via ``install_requires``) for pip. These issues are:
* **Making other libraries uninstallable.** One of pip's current dependencies is
the ``requests`` library, for which pip requires a fairly recent version to run.
If pip dependended on ``requests`` in the traditional manner, then we'd either
If pip depended on ``requests`` in the traditional manner, then we'd either
have to maintain compatibility with every ``requests`` version that has ever
existed (and ever will), OR allow pip to render certain versions of ``requests``
uninstallable. (The second issue, although technically true for any Python
@ -117,7 +117,7 @@ Debundling
As mentioned in the rationale, we, the pip team, would prefer it if pip was not
debundled (other than optionally ``pip/_vendor/requests/cacert.pem``) and that
pip was left intact. However, if you insist on doing so, we have a
semi-supported method that we do test in our CI, but requires a bit of
semi-supported method (that we don't test in our CI) and requires a bit of
extra work on your end in order to solve the problems described above.
1. Delete everything in ``pip/_vendor/`` **except** for
@ -131,6 +131,14 @@ extra work on your end in order to solve the problems described above.
3. Modify ``pip/_vendor/__init__.py`` so that the ``DEBUNDLED`` variable is
``True``.
4. *(Optional)* If you've placed the wheels in a location other than
4. Upon installation, the ``INSTALLER`` file in pip's own ``dist-info``
directory should be set to something other than ``pip``, so that pip
can detect that it wasn't installed using itself.
5. *(optional)* If you've placed the wheels in a location other than
``pip/_vendor/``, then modify ``pip/_vendor/__init__.py`` so that the
``WHEEL_DIR`` variable points to the location you've placed them.
6. *(optional)* Update the ``pip_version_check`` logic to use the
appropriate logic for determining the latest available version of pip and
prompt the user with the correct upgrade message.