-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-38662: Invoke pip via runpy, in ensurepip #18901
Conversation
This way, any changes to the internal pip API won't mean ensurepip needs to be changed as well. Also, distributors can update their pip wheels independent on CPython release schedule. Co-Authored-By: Pradyun Gedam <pradyunsg@gmail.com> Co-Authored-By: Miro Hrončok <miro@hroncok.cz>
8b5b564
to
f8008ba
Compare
Co-Authored-By: Victor Stinner <vstinner@python.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to go, to me!
Co-Authored-By: Pradyun Gedam <pradyunsg@gmail.com>
Thanks @hroncok and @pradyunsg. While it's not a major issue in CPython, I can say that being tightly coupled to pip internals is a major in Fedora which updates pip frequently and tries to support multiple pip versions. |
The ensurepip module now invokes pip via the runpy module. Hence it is no longer tightly coupled with the internal API of the bundled pip version, allowing easier updates to a newer pip version both internally and for distributors. This way, any changes to the internal pip API won't mean ensurepip needs to be changed as well. Also, distributors can update their pip wheels independent on CPython release schedule. Co-Authored-By: Pradyun Gedam <pradyunsg@gmail.com> Co-Authored-By: Miro Hrončok <miro@hroncok.cz> (cherry picked from commit 88f82b2) Co-authored-by: Miro Hrončok <miro@hroncok.cz>
GH-18906 is a backport of this pull request to the 3.8 branch. |
GH-18907 is a backport of this pull request to the 3.7 branch. |
The ensurepip module now invokes pip via the runpy module. Hence it is no longer tightly coupled with the internal API of the bundled pip version, allowing easier updates to a newer pip version both internally and for distributors. This way, any changes to the internal pip API won't mean ensurepip needs to be changed as well. Also, distributors can update their pip wheels independent on CPython release schedule. Co-Authored-By: Pradyun Gedam <pradyunsg@gmail.com> Co-Authored-By: Miro Hrončok <miro@hroncok.cz> (cherry picked from commit 88f82b2) Co-authored-by: Miro Hrončok <miro@hroncok.cz>
I wasn't even hoping for a backport. Thanks! |
The ensurepip module now invokes pip via the runpy module. Hence it is no longer tightly coupled with the internal API of the bundled pip version, allowing easier updates to a newer pip version both internally and for distributors. This way, any changes to the internal pip API won't mean ensurepip needs to be changed as well. Also, distributors can update their pip wheels independent on CPython release schedule. Co-Authored-By: Pradyun Gedam <pradyunsg@gmail.com> Co-Authored-By: Miro Hrončok <miro@hroncok.cz> (cherry picked from commit 88f82b2) Co-authored-by: Miro Hrončok <miro@hroncok.cz>
The ensurepip module now invokes pip via the runpy module. Hence it is no longer tightly coupled with the internal API of the bundled pip version, allowing easier updates to a newer pip version both internally and for distributors. This way, any changes to the internal pip API won't mean ensurepip needs to be changed as well. Also, distributors can update their pip wheels independent on CPython release schedule. Co-Authored-By: Pradyun Gedam <pradyunsg@gmail.com> Co-Authored-By: Miro Hrončok <miro@hroncok.cz> (cherry picked from commit 88f82b2) Co-authored-by: Miro Hrončok <miro@hroncok.cz>
@petdance: Do you have an idea why your CPython fork creates almost 20 new " petdance added a commit to petdance/cpython that referenced this pull request" comments??? I see that https://github.com/petdance/cpython/commit/c861affb02eb7a4a90d7c34f86c743545551d8a4 commit starts with " bpo-38662: ensurepip invokes pip via runpy (GH-18901) ". What is this "(GH-18901)" syntax? do you rewrite the Python history? |
I'm sorry, I don't know what's happening. My normal process is to pull from upstream master daily, and then rebase my working branches against it my new master. Then I push the branches back. I'm not changing any history. I don't know what the "GH-18901" syntax is. Clearly c861affb02eb7a4a90d7c34f86c743545551d8a4 somehow got created on my |
In the master branch, the "bpo-38662: ensurepip invokes pip via runpy (GH-18901)" has the sha1: 88f82b2. In your repository, it has the sha1: c861affb02eb7a4a90d7c34f86c743545551d8a4 and the title "bpo-38662: ensurepip invokes pip via runpy (GH-18901)". Something replaced "GH-18901" with "GH-18901". "GH-18901" syntax is used in Python to mean "identifier 18901 in the GitHub namespace", as bpo-123 is "123 in the bugs.python.org namespace".
How do you pull commits from GitHub? Which tools/commands are you using? |
That's it. Maybe I screwed up a commit on my one |
Try maybe to clone again a fresh copy of the cpython Git repository and restart from that point. |
I deleted my |
You added two more commmits to this PR :-)
and
"I deleted my calloc branch" Aha. I added PyMem_Calloc(). I recall that I ran some benchmarks. Tell me if you want me to have a look at your PR. |
The two weird commits have nothing to do with the calloc branch, though. :-( Is there a bpo ticket you'd like me to add a calloc PR to? It's just 16 places where I changed malloc+memset to calloc. |
If you want to make changes related to calloc, please open a new issue. I'm not aware of an open issue related to calloc. |
JFYI I've unsubscribed. If there is anything related to this PR itself that needs my attention, please do mention me. |
This way, any changes to the internal pip API won't mean ensurepip needs to be
changed as well. Also, distributors can update their pip wheels independent on
CPython release schedule.
Co-Authored-By: @pradyunsg
Closes #17029
https://bugs.python.org/issue38662