This commit solves a dependency issue between twine and
importlib-metadata which resulted in our deploy-pipeline on Appveyor to
fail [1].
Essentially whats going on is that pip finds an already installed,
older version (v3.4.0) of importlib-metadata when installing twine. The
dependency resolver in pip, prior to version 20.3, ignores twine's
minmum-requirement for importlib-metadata (v3.6.0) and keeps the old
version, as can be seen from the logs of the failing build:
$ IF DEFINED PYTHON pip install --upgrade twine wheel
...
Requirement already satisfied, skipping upgrade:
importlib-metadata; python_version < "3.8" in
c:\python36\lib\site-packages (from twine) (3.4.0)
...
This to-old importlib-metadata version causes twine to fail when we
later try to upload the wheels to pypi. In version 20.3 pip got a new
dependency resolver, that does not ignore the twine requirements and
do upgrade the importlib-metadata version when installing twine.
This commit solves a dependency issue between twine and importlib-metadata which resulted in our deploy-pipeline on Appveyor to fail [1].
Essentially whats going on is that pip finds an already installed, older version (v3.4.0) of importlib-metadata when installing twine. The dependency resolver in pip, prior to version 20.3, ignores twine's minmum-requirement for importlib-metadata (v3.6.0) and keeps the old version, as can be seen from the logs of the failing build:
This to-old importlib-metadata version causes twine to fail when we later try to upload the wheels to pypi. In version 20.3 pip got a new dependency resolver, that does not ignore the twine requirements and do upgrade the importlib-metadata version when installing twine.
[1] https://github.com/pypa/twine/issues/729