Now that the issue with invalid coverage data has been fixed.

Fix error with PEP 517 builds when wheel exists (GH #1761)

Limit workers in ProcessPoolExecutor

As a mitigation for #1730, this commit limits the number of workers in
the ProcessPoolExecutor to 1 (default is the number of CPUs). On PyPy,
having a higher number of available workers dramatically increases the
number of concurrent processes, leading to some resource exhaustion
issues.

This does not address the root issue, but should improve the situation
until the root issue is addressed.

Use xenial and latest pypy3 on Travis CI.

As it will soon become the default: https://blog.travis-ci.com/2019-04-15-xenial-default-build-environment

`build_meta.build_wheel` assumes that the only wheel in its output
directory is the one it builds, but prior to this, it also used the
`dist/` folder as its working output directory. This commit uses a
temporary directory instead, preventing an error that was triggered when
previously-generated wheel files were still sitting in `dist/`.

Fixes GH #1671

Add failing test for issue #1671 (ValueError when .whl is present)

Currently, this will fail because setuptools.build_meta.build_wheel
assumes that no wheels already exist in the `dist/` directory.

See GH #1671

Update super old CHANGES.rst dead links

FIX: git and hg revision checkout under Windows

Checking for new implementation solving issue #1740

Windows does not change the working directory for a process via `cd .. && <process>` (see e.g. this question: https://stackoverflow.com/q/55641332/8575607 ). This commit replaces the use of `cd .. &&` with arguments provided by `git` and `hg` respectively.

uniquify paths in PYTHONPATH

When reading config files, require them to be encoded with UTF-8.

Update changelog for version 40.9.0

Include path in error message when version is missing (Fixes #1664)

Related to pip's github issue pypa/pip#6194.

This has come up in pip's issue tracker (github) multiple times:

  - pypa/pip#6177
  - pypa/pip#6283
  - pypa/pip#6194

Update pypy in travis

There is some issue with pypy2.7-5.8.0 in Travis. This probably does not
solve the *root* issue, but updating the pypy version does seem to fix
the build, so in the interest of unblocking the project, we will merge
this change.