The message looks like this:
File "setup.py" not found. Directory cannot be installed in editable
mode: <absolute-dir-path>
(A "pyproject.toml" file was found, but editable mode currently
requires a setup.py based build.)
- check build requirements for conflicts
- better isolation (ignore system site packages)
- support 2 prefixes: a "normal" one, and an "overlay" one
(with higher priority over "normal")
- cleanup virtualenv creation code
- ensure all testing virtual environments use a recent version
of setuptools / wheel, making it easier to switch to custom
versions of those, as well as reducing network accesses
- reduce size of testing virtual environment, slightly speeding
up the testsuite
* Move dist restriction options to be re-usable (between install/download)
* Make dist restriction options usable in `install` (exclusively with --target)
* Add a check_supported_wheels bool to RequiriementSet for non-resolved (full path) dependencies
Offload more work to the underlying pip command used to install the
build requirements, so there's no need to duplicate code to handle
environment markers/extras. This is done by setting the correct options
from the finder passed in argument to `_install_build_reqs`.
- avoid hitting the index: use `common_wheels`/`script.pip_install_local`
- use `script.pip(..., use_module=True)` to simplify some tests
- improve `test_pep518_uses_build_env` parametrization
- simplify `test_pep518_with_user_pip`: we only need to check build
requirements can be installed, so no need for testing with both
`install` and `wheel` command
- fix `test_pip_wheel_with_pep518_build_reqs_no_isolation`: building
pep518-3.0 without isolation should fail if the build requirements
are not installed.
* fix build environment handling when using PyPy
* do use the build environment for all build commands
* allow installing and building a wheel of a PEP 518 enabled
package without prior installation of setuptools and/or wheels
* fix check for minimum supported requirements for PEP 518 support:
- correctly handle complex requirements
- both setuptools and wheels are needed
This test relies on buggy setuptools behaviour (keeping
requirements with environment markers in install_requires,
rather than moving them to extras_require) which has been
fixed in recent setuptools versions.
The use of environment markers implies that the user expects the
packages to not be installed in some cases (eg depending on version
of Python), so the log output shouldn't be classed as a warning,
particularly since this results in it being sent to `stderr` rather
than `stdout`.
Fixes#4876.
This essentially allows me to do an overall check general check by running the tests using pytest's `-k basic` syntax. Given that I like running tests often and that, in general, I make typos more often than changes that break core functionality, I think this will reduce cycle times for me.
Installed files are recorded by Pip in the order the underlying tool
(Distutils, Setuptools, ...) recorded them.
Unfortunately, at least Setuptools doesn't record them in a
deterministic order in the case of a directory being installed, as it
uses os.walk to find the list of files.
We could fix all those underlying tools to record their files in a
deterministic order in all situations. But fixing it once here in Pip
for all tools is certainly simpler and more future-proof.
This makes the installation more reproducible, and therefore more
verifiable.
* fix test not using temporary directory
* avoid creating a `cache_dir` directory in the source tree
* drop `data` fixture from tests that don't use it
* tests: fix pytest warning
Also, reduce the number of test cases because these tests take too long.
The issue is that the setup and teardown of the test environment takes a
long time, and in order to reuse the same test environment, we must
perform install/uninstall cycles to test different URL and path formats.
A better approach might be to generate `FSPkg` using a function that
writes the `setup.py` and `__init__.py` files to a new directory. The
test packages would be easy to generate and save the uninstall time.
For now, we reduce the number of URL/path formats tested, since the
previous test coverage was even more limited.
Tests are timing out and also not following requirements/install test
factorization. Split to conform to test organization and to prevent
test timeout.
We want the root logger to output debug level logs when we have
specified "--log". The log-file handler then sends this to our file,
and the other handlers (console) filter out at their appropriate
level.
This restores the intended behaviour of "--log" argument, which is
supposed to output verbose logs to a file always.
A test-case is added
Closes: #3351
Commit 5bb989993 added some code for hiding/showing the cursor when
running on the terminal, but accidentally made it so that it always
printed the invisible control codes, even when not on a tty or when
--quiet was specified. This turns out to be surprisingly bad (e.g. it
breaks the official docker python builds). So, let's not do that.
Fixes gh-3418
Since pip 7, via pip freeze, is producing such mismatching #egg
fragment, forbidding them in pip 8 would be too strongly
backward-incompatible.
It is a partial rollback of 1a012bb6.
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
* Add --require-hashes option. This is handy in deployment scripts to force application authors to hash their requirements. It is also a convenient way to get pip to show computed hashes for a virgin, unhashed requirements file. Eventually, additions to `pip freeze` should fill a superset of this use case.
* In --require-hashes mode, at least one hash is required to match for each requirement.
* Option-based requirements (--sha256=...) turn on --require-hashes mode implicitly.
* Internet-derived URL-based hashes are "necessary but not sufficient": they do not satisfy --require-hashes mode when they match, but they are still used to guard against transmission errors.
* Other URL-based requirements (#md5=...) are treated just like flag-based ones, except they don't turn on --require-hashes.
* Complain informatively, with the most devastating errors first so you don't chase your tail all day only to run up against a brick wall at the end. This also means we don't complain that a hash is missing, only for the user to find, after fixing it, that we have no idea how to even compute a hash for that type of requirement.
* Complain about unpinned requirements when hash-checking mode is on, lest they cause the user surprise later.
* Complain about missing hashes.
* Complain about requirement types we don't know how to hash (like VCS ones and local dirs).
* Have InstallRequirement keep its original Link around (original_link) so we can differentiate between URL hashes from requirements files and ones downloaded from the (untrustworthy) internet.
* Remove test_download_hashes, which is obsolete. Similar coverage is provided in test_utils.TestHashes and the various hash cases in test_req.py.
`pip download` has the same functionality as `pip install --download`,
and the behavior of `pip install --download` is preserved with a deprecation
warning. `pip install --download` will be removed in pip version 10.
Using --install-options, --build-options, --global-options changes
the way that setup.py behaves, and isn't honoured by the wheel code.
The new wheel autobuilding code made this very obvious - disable
the use of wheels when these options are supplied.
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.
This fixes 2 aspects of `pip install output`:
1. When `pip install` succeeds, it's still printing a lot of output from
the package's setup.py. The average consumer of Python packages, when
they do `pip install lxml`, probably doesn't care to see a bunch of
output about:
- copying files to a `build` directory
- installing and running Cython
- compiling C code
This is noise to most when the `pip install` succeeds. It's useful to
see all the output when the install fails, which is the subject of #2
below. On success, the output is now very clean with 5 short lines:
$ pip install lxml
Collecting lxml
Using cached lxml-3.4.2.tar.gz
Installing collected packages: lxml
Running setup.py install for lxml
Successfully installed lxml-3.4.2
2. When there's an error from `pip install`, it's annoying to have to
scroll through 2 different copies of the failure output (especially when
one is filtered and one is unfiltered so one might have stuff that the
other doesn't). This makes it not print the filtered version so that
there is just the unfiltered version and nothing is repeated.
$ pip install ~/dev/git-repos/lxml
Processing /Users/marca/dev/git-repos/lxml
Installing collected packages: lxml
Running setup.py install for lxml
Complete output from command ...
cc -c /var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/xmlCheckVersion4tBaVV.c -o var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/xmlCheckVersion4tBaVV.o
/var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/xmlCheckVersion4tBaVV.c:1:10: fatal error: 'libxml/xmlversion.h' file not found
#include "libxml/xmlversion.h"
^
1 error generated.
----------------------------------------
Command "/Users/marca/python/virtualenvs/pip/bin/python -c ...
None of the lines above are repeated.
1. Check for the existence of a directory before copying from temporary directory to final target. If it exists, warn the user.
2. If the user specifies the --upgrade option and the directory exists, delete it and continue with installation.
3. Adding tests for above cases.
This resolves#1489, #1710 completely and parts of #1833.
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.
* Move virtualenv creation out of TestPipEnvironment
* Remove global state and force explicit use of TestPipEnvironment
instances
* Remove "backup" virtualenv copying and instead create new
virtual environments each time.
* Remove the monkeypatched "PyPICache" functionality
* Remove things that were not being used anymore and were dead
weight
* Remove sitecustomize support which was primarily used to
monkeypatch the "PyPICache" but was used in one or two other
tests.
* Better output with the bare asserts we use throughout the tests
* Function fixtures are pretty nice, especially as a way to
start a background server or create an isolated virtualenv
