-
Notifications
You must be signed in to change notification settings - Fork 239
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
Try using ensurepip instead of get-pip #665
Conversation
Hmm. It was working, but the 3.8.10 update broke it on mac! I wonder what changed... |
Cross-linking to #210. Great that it does now seem to be working! :-) |
This is ready to go I think. To explain what's going on here, we need to ensure that pip is available on PATH as So, to ensure that This seems okay, but alternative ideas welcome! |
cibuildwheel/macos.py
Outdated
try: | ||
call(["python", "-m", "pip", "--version"], env=env, cwd="/tmp") | ||
except subprocess.CalledProcessError: | ||
pip_is_installed = False | ||
else: | ||
pip_is_installed = True |
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.
This feels slightly overkill with an exception. How about adding check: bool=True
to call
, then passing check=check
through to subprocess.run
, and return the result? Then this could be:
pip_is_installed = call(["python", "-m", "pip", "--version"], env=env, cwd="/tmp", check=False).returncode == 0
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.
(same thing for Windows)
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.
haha, yes that was my first instinct, too. You can see it here:
ef91635
However, I ended up (#665 (comment)) changing that to the exception form because
- adding the
check
argument tocall()
is awkward, because it looks a lot like theenv
andcwd
arguments, that passthrough tosubprocess.run
, but there's a subtle difference - a different default. - adding the return type CompletedProcess to
call()
is also awkward, because it's only useful whencheck=False
. - it muddles
call()
's purpose, it's no longer 'do this' it's now 'do this/try this and tell me what happened'
So I thought the exception was neater overall.
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.
Our entire wrapper is a bit bothersome - the important thing it does is add logging. It also happens to modify the interface just a tiny bit (different name, check=True). This is heavily because it was a shortcut for check_call
, but we've standardized on run(check=True)
, which is the recommended method to use for 3.5+ code. So what about renaming the wrapper to utils.run
, just passing **kwargs
, and adding check=True
for most of the uses? I'd rather make it look like something people are used to (subprocess.run), rather than save a few chars.
Now if it was dramatically better, ala plumbum, then it would be worth learning something new. But not for just a small interface change.
Could be updated later, of course, doesn't have to be in this PR.
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.
Points 2 and 3 are just inherited from subprocess.run
. The interface might not be ideal, but it's in the stdlib.
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.
Would using:
call(["python", "-m", "ensurepip"], env=env, cwd="/tmp")
call(
["python", "-m", "pip", "install", "--force-reinstall", "pip", *dependency_constraint_flags],
env=env,
cwd="/tmp",
)
solve the issue of detecting if pip is installed in the first place ?
i.e. use --force-reinstall
instead of --upgrade
when installing the pinned version
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.
Would that ensure the defaultpip script was there? I think so?
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.
Given that an actual update would end-up in the place where we want to be and starts by removing the existing installation of pip, I would guess so. Let's try this. @joerick, I'll push a commit, please do revert it if you don't like what you're seeing :-)
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.
I agree- if that works, I'm interested. Let's see.
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.
I'm happy if we can get rid of this internal pip copy! :)
Cool, that worked! I just want to check out test suite timings though, it occurs to me that this might be reinstalling pip on every test now, which could be adding some time that we could do without... |
Weren't we doing that before? The pinned pip was never the bundled pip. |
True, but when running our integration tests, each test reuses the same environment, so once the pinned pip is installed, it doesn't get reinstalled on each test.
There's quite a lot of variance in these figures, so I'm not totally sure, but it does look like an increase on windows... let me try adding back the check for installation_dir/bin/pip before doing the reinstall, maybe we'll see a decrease. |
updated table with the last commit-
|
Looks like it's a bit faster with a check around the |
That looks promising this way. |
Really nice idea 👍 |
cibuildwheel/macos.py
Outdated
# ensure pip is installed | ||
call(["python", "-m", "ensurepip"], env=env, cwd="/tmp") | ||
|
||
# upgrade to the version matching our constraints | ||
# if necessary, reinstall it to ensure that it's installed as 'pip' | ||
requires_reinstall = not (installation_bin_path / "pip").exists() |
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.
maybe move python -m ensurepip
below requires_reinstall
to get rid of this call as well ?
requires_reinstall = not (installation_bin_path / "pip").exists()
if requires_reinstall:
# ensure pip is installed
call(["python", "-m", "ensurepip"], env=env, cwd="/tmp")
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.
hmm. yeah, I guess it would be a little faster? I thought 'ensurepip' was a quick noop when it's installed, but it still takes around a second on my machine. I'll try your suggestion.
GHA having issues - https://www.githubstatus.com/ |
updated table with the last commit-
|
updated table with the last commits (no code changes)-
In summary, there might be too much variance in the Azure Windows figures to conclude anything, but the GHA WIndows ones seem fairly stable. Conversely the Mac figures are more stable on Azure! Either way, this seems good to go 👍 |
thanks for spotting that license note henry! |
Eliminating get-pip.py removes a vendored dependency.