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

is there an option to have get-pip.py installing pip without downloading from internet ? #2351

Closed
stonebig opened this Issue Jan 13, 2015 · 15 comments

Comments

Projects
None yet
7 participants
@stonebig
Contributor

stonebig commented Jan 13, 2015

hello,

Is there a way to have python Scripts\get-pip.py to install pip (and setuptools) only from itself ?
(not going to internet)

(on python 3.3, windows)

@cgohlke

This comment has been minimized.

cgohlke commented Jan 14, 2015

Not from itself. To avoid downloading from the internet try python get-pip.py --no-index --find-links=. and place pip and setuptool wheels in . (or another local path). See https://pip.pypa.io/en/latest/installing.html#install-pip

@pfmoore

This comment has been minimized.

Member

pfmoore commented Jan 14, 2015

get-pip does include a copy of pip. But not in the form of a wheel, or anything you would be able to install it from. It's not intended for that - it's for people for whom "download a script and run it" is as complex as they want to get.

If you are OK with downloading the pip wheel manually, and doing something unsupported, you can use the pip wheel to install itself like this:

python pip-6.0.6-py2.py3-none-any.whl/pip install --no-index pip-6.0.6-py2.py3-none-any.whl

You can download other wheels (such as setuptools) and add them to the end of the command line if you want. It won't install from sources, though.

I repeat - this isn't supported, so if it stops working or goes wrong, you get to debug and fix it yourself ;-)

@stonebig

This comment has been minimized.

Contributor

stonebig commented Jan 14, 2015

issue #2328 is the only one I care to the point of fixing it, because it's critical at the moment and I have no simpler workaround.

Simple is better than complex

@stonebig stonebig closed this Jan 14, 2015

@cgohlke

This comment has been minimized.

cgohlke commented Jan 14, 2015

python pip-6.0.6-py2.py3-none-any.whl/pip install --no-index pip-6.0.6-py2.py3-none-any.whl

Thank you. That's nice. No network connection required and more universal and reliable than ensurepip. Maybe worth adding to the documentation.

@dstufft

This comment has been minimized.

Member

dstufft commented Jan 14, 2015

More reliable than ensurepip?

@cgohlke

This comment has been minimized.

@dstufft

This comment has been minimized.

Member

dstufft commented Jan 14, 2015

I mean, ensurepip essentially does the exact same thing as python pip-6.0.6-py2.py3-none-any.whl/pip install --no-index pip-6.0.6-py2.py3-none-any.whl. That just looks like a bug in mimetypes that we might have just fixed in pip 6.0. I would guess if you were getting those errors and you were using pip-1.5.6-py2.py3-none-any.whl that you'd get the same error.

@cgohlke

This comment has been minimized.

cgohlke commented Jan 14, 2015

Yes, you are right. But it is easier to distribute a updated pip wheel than wait for the Python bug to be fixed.

@dstufft

This comment has been minimized.

Member

dstufft commented Jan 14, 2015

Sure :)

Hopefully the next 3.4 will have it fixed anyways, since 3.4.2 has pip 6.0.6 too!

@pfmoore

This comment has been minimized.

Member

pfmoore commented Jan 14, 2015

@dstufft would you consider the trick of invoking the wheel directly to be supported? (It's not like it'll ever stop working without breaking at least one of get-pip or python -m pip). If it's OK for people to use (in special circumstances) it might well be worth adding to the docs as an "advanced" option.

@dstufft

This comment has been minimized.

Member

dstufft commented Jan 14, 2015

Well, it might stop working. The thing with get-pip.py, virtualenv, and python -m ensurepip is that they are setup to work with a specific wheel file. So if a new version of Wheel comes out which no longer supports that (or which requires something different in order to actually invoke it) it won't effect those projects without having to manually update the Wheel files inside of them (and at the same time, updating that code to handle the new layout).

Officially PEP 427 says:

Technically, due to the combination of supporting installation via simple extraction and using an archive format that is compatible with zipimport , a subset of wheel files do support being placed directly on sys.path . However, while this behaviour is a natural consequence of the format design, actually relying on it is generally discouraged.

Firstly, wheel is designed primarily as a distribution format, so skipping the installation step also means deliberately avoiding any reliance on features that assume full installation (such as being able to use standard tools like pip and virtualenv to capture and manage dependencies in a way that can be properly tracked for auditing and security update purposes, or integrating fully with the standard build machinery for C extensions by publishing header files in the appropriate place).

Secondly, while some Python software is written to support running directly from a zip archive, it is still common for code to be written assuming it has been fully installed. When that assumption is broken by trying to run the software from a zip archive, the failures can often be obscure and hard to diagnose (especially when they occur in third party libraries). The two most common sources of problems with this are the fact that importing C extensions from a zip archive is not supported by CPython (since doing so is not supported directly by the dynamic loading machinery on any platform) and that when running from a zip archive the file attribute no longer refers to an ordinary filesystem path, but to a combination path that includes both the location of the zip archive on the filesystem and the relative path to the module inside the archive. Even when software correctly uses the abstract resource APIs internally, interfacing with external components may still require the availability of an actual on-disk file.

Like metaclasses, monkeypatching and metapath importers, if you're not already sure you need to take advantage of this feature, you almost certainly don't need it. If you do decide to use it anyway, be aware that many projects will require a failure to be reproduced with a fully installed package before accepting it as a genuine bug.

Personally I'd say that I wouldn't document it as it certainly is an advanced usage and I believe it should be generally discouraged, but I'd say that is a -0 not a -1 so if you or someone else feels strongly about it I wouldn't be upset if we did document it.

@pfmoore

This comment has been minimized.

Member

pfmoore commented Jan 14, 2015

Nope, I'm happy enough to just leave it as a consequence of the way wheels work. It just strikes me as kind of neat that it does work...

@myloginid

This comment has been minimized.

myloginid commented Nov 30, 2015

Thanks for python pip-6.0.6-py2.py3-none-any.whl/pip install --no-index pip-6.0.6-py2.py3-none-any.whl

@geekyfox90

This comment has been minimized.

geekyfox90 commented Jun 19, 2017

+1

@xialu4820723

This comment has been minimized.

xialu4820723 commented Sep 13, 2018

all vesions of pip whl can be downloaded here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment