Downloading is done at the end of the download command
just like any other requirement. This is necessary to avoid
archiving editable requirements to a zip file when running
pip wheel.
Previously we were copying an existing wheel to a file with a
different distribution name. When using stricter metadata parsing this
would fail, so now we use a more conformant dummy wheel function.
This and the next several changes will uncouple the tests from the
current implementation, allowing us to factor the actual file download
out of `unpack_file_url` and `unpack_http_url`.
As mentioned in https://snarky.ca/the-challenges-in-designing-a-library-for-pep-425/
this tag doesn't make much sense + it impedes our usage of
packaging.tags.
In terms of backwards-compatibility, we attest to try to match
compatible wheels as best as possible, and this tag doesn't represent
that.
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.
With the --platform option, a user can download wheels with
a different platform than that of the local machine running the command.
With the --python-version option, a user can
download wheels that are explicitly compatible with a specific
Python interpreter version.
This functionality is meant for utilities that gather dependencies
and prepare distributions for other platforms.
`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.
Nguyễn Gia Phong
