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

[stonebig]

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]

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]

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]

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

[cgohlke]

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]

More reliable than ensurepip?

[cgohlke]

I was referring to http://bugs.python.org/issue22028 and https://mail.python.org/pipermail/python-list/2015-January/696660.html

[dstufft]

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]

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

[dstufft]

Sure :)

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

[pfmoore]

@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]

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]

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]

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]

+1