6.1.1 and before use git clones when installing a git+ url. 7.0.0.dev
didn't temporarily because the internal flag for controlling whether
to do a clone or an export was tied into the behaviour for whether
something will be deleted or not - which is arguably different. Remove
the confounded behaviour and just unpack always, using the same marker
flag to delete directories as used for file and non-vcs urls.
E.g.: `pip install /path/to/dir`
by building an sdist and then unpacking it instead of doing
`shutil.copytree`. `shutil.copytree` may copy files that aren't included
in the sdist, which means that:
1. If those files are large, a `pip install` could take much longer than
it should.
2. Folks that are using `python setup.py install` to test their package
are not fully testing it, because it may copy over files that wouldn't
be there if they built and sdist and installed that.
So this method building an sdist is both more accurate and faster.
Fixes https://github.com/pypa/pip/issues/2195
In _download_url pip was checking the download hash in a finally block
so that it was always checked regardless of download success. This is
problematic when downloads fail in a way that will make the hash check
fail. For example, downloading zero bytes so that a zero byte file is
hashed. When this happens the hash mismatch is reported to the user and
not the underlying network issue that was run into.
Fix this by removing the try finally block completely so that early
errors are bubbled up and reported to users.
Fix issue 2332
instead of just filename when using index other than PyPI.
It's useful to distinguish between downloading from PyPI or from an
internal devpi server, for example. In the latter case, it is useful to
see the full URL, to know which index pip is downloading from.
E.g.:
Downloading from PyPI is unchanged:
$ pip install --no-cache-dir --ignore-installed Jinja2
...
Downloading Jinja2-2.7.3.tar.gz (378kB)
But downloading from a different server results in displaying the full
URL:
$ pip install --no-cache-dir --ignore-installed -i http://mirror.picosecond.org/pypi/simple jinja2
...
Downloading http://mirror.picosecond.org/pypi/packages/source/J/Jinja2/Jinja2-2.7.3.tar.gz (378kB)
To facilitate detection of pip in scenarios where parsing JSON isn't
easy but simple string matching is, change the User-Agent to be of
the form "pip/{version} {json}" instead of just "{json}".
The contents of the JSON data has not changed.
This is a rebased final version of a proposed solution to fix
issues #932, #1104 & #1180. Following changes have been done:
* Implemented a new class `PipXmlrpcTransport` using a
contained `PipSession` object.
* Modified the `pip/commands/search.py` to make use of the
`PipXmlrpcTransport` class.
* Properly initialized options for testing `SearchCommand`:
- Changed `options_mock` to an `options` object built from
`parse_args`, to properly initialize default options.
* Deprecates the --download-cache option & removes the download
cache code.
* Removes the in memory page cache on the index
* Uses CacheControl to cache all cacheable HTTP requests to the
filesystem.
* Properly handles CacheControl headers for unconditional
caching.
* Will use ETag and Last-Modified headers to attempt to do a
conditional HTTP request to speed up cache misses and turn
them into cache hits.
* Removes some concurrency unsafe code in the download cache
accesses.
* Uses a Cache-Control request header to limit the maximum
length of time a cache is valid for.
* Adds pip.appdirs to handle platform specific application
directories such as cache, config, data, etc.
If Pip is using an index url that starts with http:// or https://, and
it gets a 404, it does Magic(TM) to figure out what the real name of the
package is. The code looks as though it's intended to do this for
file:// urls as well - but it doesn't, because nothing catches the
OSError that gets raised when the first stat fails.
In order to let this failure be handled and let the usual logic kick in,
set the response status to 404 and let the error bubble up.
