Compare extras when checking if a requirement has already been
specified, and take a union of the extras before installation.
Co-Authored-By: Sachi King <nakato@nakato.io>
Closes#3046, #3189
With wheel autobuilding in place a release blocker is some granular
way to opt-out of wheels for known-bad packages. This patch introduces
two new options: --no-binary and --only-binary to control what
archives we are willing to use on both a global and per-package basis.
This also closes#2084
Building wheels before installing elminates a cause of broken environments -
where install fails after we've already installed one or more packages.
If a package fails to wheel, we run setup.py install as normally.
This is needed for setup-requires, since without it its possible
to cause installation to fail in sort-circuit scenarios such as
the added functional test case demonstrates.
use pkg_resources.Distribution.requires instead of
Requirements.requirements to have environment markers parsing for free
It also unifies a little the process for wheel and non-wheel installs
closes#2174
Default from pip 1.6 will be to always use wheels, so the --use-wheels
in requirements.txt is now deprecated. However, the --no-use-wheels
is introduced to be able to disable wheel usage via requirements.txt.
In Python 2, the exec statement handles encoding for us, but in
Python 3 the encoding must be specified when opening the file
(if it's not specified it uses the system locale encoding, so
previously this would work only if your locale environment variables
specified the same encoding as the setup.py file).
On Python 3.2+ the tokenize.open function is available to interpret
the encoding declaration; fixing this for python 3.0 and 3.1 is more
difficult.
In Python 2, the exec statement handles encoding for us, but in
Python 3 the encoding must be specified when opening the file
(if it's not specified it uses the system locale encoding, so
previously this would work only if your locale environment variables
specified the same encoding as the setup.py file).
On Python 3.2+ the tokenize.open function is available to interpret
the encoding declaration; fixing this for python 3.0 and 3.1 is more
difficult.
