One of the downsides of pip's new hiding of build chatter is that for
packages that take a very long time to build (e.g. scipy) the user gets
no indication that anything is happening for a very long time (e.g. tens
of minutes), and is likely to get frustrated and hit Control-C. This can
also create issues for automated systems that kill jobs that don't
produce occasional output (e.g. Travis-CI).
This commit implements an idea discussed here:
https://github.com/pypa/pip/issues/2732#issuecomment-153215371
where we put up a spinner that rotates whenever the underlying build
produces output. I tried it on scipy, and it the experience was quite
pleasant! It spun around, sometimes fast and sometimes slow, and then
there was one uncomfortable pause for ~1 minute while a very gnarly C++
file got compiled, but that's okay because it was actually providing
accurate feedback.
It looks like:
```
Running setup.py install for scipy ... /
Running setup.py install for scipy ... -
Running setup.py install for scipy ... \
Running setup.py install for scipy ... done
```
or if the command has non-zero return code, or an exception is raised,
you get:
```
Running setup.py install for scipy ... /
Running setup.py install for scipy ... -
Running setup.py install for scipy ... \
Running setup.py install for scipy ... error
```
A lot of existing tarballs will successfully build a wheel, but the
wheel will be implicitly broken because they will have dynamically
adjusted the install_requires inside of their setup.py. Typically
this is done for things like Python version, implementation, or what
OS this is being installed on. We don't consider cache directories
to be OS agnostic but we do consider them to be Python version and
implementation agnostic. To solve this, we'll force the cached
wheel to use a more specific Python tag that includes the major
version and the implementation.
format_exc takes only one argument, limit which should be an integer.
python 2 seems more lenient than python 3 on that point.
mistake introduced in commit 3148b967a
The changes resolves a condition that can lead to a stacktrace due to the
use of constraint files. There are several conditions where the result
object may be left undefined which causes the problems.
``` traceback
Exception:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 211, in main
status = self.run(options, args)
File "/usr/local/lib/python2.7/dist-packages/pip/commands/wheel.py", line 180, in run
wheel_cache
File "/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 266, in populate_requirement_set
requirement_set.add_requirement(req)
File "/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 267, in add_requirement
return result
UnboundLocalError: local variable 'result' referenced before assignment
```
This change simply ensures that the 'result' object is a defined
when the method returns.
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
Removed the mention of "package index options" in the docs, because they don't all fit that category anymore. Not even --no-binary and --only-binary do; they're "install options".
This would occur when, for example, installing from a requirements file that references a certain hashed sdist, a common situation.
As of pip 7, pip always tries to build a wheel for each requirement (if one wasn't provided directly) and installs from that. The way this was implemented, InstallRequirement.link pointed to the cached wheel, which obviously had a different hash than the index-sourced archive, so spurious mismatch errors would result.
Now we no longer read from the wheel cache in hash-checking mode.
Make populate_link(), rather than the `link` setter, responsible for mapping InstallRequirement.link to a cached wheel. populate_link() isn't called until until prepare_files(). At that point, when we've examined all InstallRequirements and their potential --hash options, we know whether we should be requiring hashes and thus whether to use the wheel cache at all.
The only place that sets InstallRequirement.link other than InstallRequirement itself is pip.wheel, which does so long after hashes have been checked, when it's unpacking the wheel it just built, so it won't cause spurious hash mismatches.
setuptools.package_index.local_open is used for file: URLs, and only
handles directories if the URL ends with a slash. Add the trailing
slash to pip's documentation to reduce confusion.
are unavailable, but issue a warning if this is used.
2. Explicitly handle the case where the unicode detection finds wide
unicode but this is a 3.3+ build (necessary due to #1)
3. Fix tests broken due to #2.
Pythons with PEP 393 Flexible String Representation (so >= 3.3).
Granted, on these Pythons, the SOABI config var should always be set,
but the manual SOABI code path should still try to do the right thing.
Additionally, fix the version portion of the Python tag on wheels built
with PyPy that use the Python API. It will now be the Python major
version concatenated with the PyPy major and minor versions.
Fixes#2671, #2882.
Renaming "gots" didn't go well. I think the current naming is the most concise way to put it. If we rename it to "got", then the loop iterator can't be called "got", and the simple relationship between the iterator and collection names is lost. "Actual" and "actuals" are the other names that occurred to me, but they look so much like "allowed" that the code becomes harder to read.
