Since zips don't typically contain directory entries, we want to
only operate on files. Adding files to the .dist-info tests means we
will be able to reuse them for both cases, while they coexist.
Since retrieval of the .dist-info dir already ensures that a
distribution is found, this reduces responsibility on wheel_metadata and
lets us remove a few tests already covered by the tests for
test_wheel_dist_info_dir_*.
This will let us re-use the wheel_metadata for other parts of
processing, and by parameterizing checks in terms of metadata we will be
able to substitute in metadata derived directly from the zip.
* Raise exception on exception in finding wheel dist
We plan to replace this code with direct extraction from a zip, so no
point catching anything more precise.
* Raise exception if no dist is found in wheel_version
* Catch file read errors when reading WHEEL
get_metadata delegates to the underlying implementation which tries
to locate and read the file, throwing an IOError (Python 2) or OSError
subclass on any errors.
Since the new explicit test checks the same case as brokenwheel in
test_wheel_version we remove the redundant test.
* Check for WHEEL decoding errors explicitly
This was the last error that could be thrown by get_metadata, so we can
also remove the catch-all except block.
* Move WHEEL parsing outside try...except
This API does not raise an exception, but returns any errors on the
message object itself. We are preserving the original behavior, and can
decide later whether to start warning or raising our own exception.
* Raise explicit error if Wheel-Version is missing
`email.message.Message.__getitem__` returns None on missing values, so
we have to check for ourselves explicitly.
* Raise explicit exception on failure to parse Wheel-Version
This is also the last exception that can be raised, so we remove
`except Exception`.
* Remove dead code
Since wheel_version never returns None, this exception will never be
raised.
This reverts commit bcad1b1cb5, reversing
changes made to f86490317a.
As discussed, we should rethink the interface of this command output as
part of larger CLI usability review. In the interim, the same
functionality can be achieved using straightforward shell commands.
This is a more appropriate place for the function, since it is more
related to tags than wheels, and will make it easier to refactor Wheel
into its own module.
This reduces the number of required arguments and helps establish a
convention for install_* functions, which should take a scheme instead
of the individual components.
* Add SHA256 hash of .whl as info output
Currently I'm trying to debug some issues with what appear to be
corrupt wheels. It would be very useful to see what pip thought the
state of things was as it wrote the wheel output; if a final corrupt
distributed file is then different to what pip has saved in its build
logs, you know the problem is somewhere after pip but before
distribution.
Currently we get a log of the initial creation, then the stamp when it
gets moved in the final output location, e.g.:
creating '/tmp/pip-wheel-71CpBe/foo-1.2.3-py2.py3-none-any.whl
...
Stored in directory: /opt/wheel/workspace
A lot happens in between this, so my suggestion is we add the final
output file and it's hash before the "Stored in directory:", e.g. you
now see:
Building wheels for collected packages: simple
Running setup.py bdist_wheel for simple: started
Running setup.py bdist_wheel for simple: finished with status 'done'
Finished: simple-3.0-py3-none-any.whl sha256=39005a57a6327972575072af82e11d0817439fe6a069381f6f2a123a8c0bf1cf
Stored in directory: /tmp/pytest-of-iwienand/pytest-18/test_pip_wheel_success0/workspace/scratch
Successfully built simple
Despite the hash being fairly important for things like
--require-hashes, AFAICS the final hash is not put in the logs at all
currently, so I think this is generically helpful.
* Reword wheel hash details output
This rewords the output to be more like the form of the preceding
messages. Additionally the size is added, since we have calculated it
anyway. The output will now look like:
Collecting simple==3.0
Building wheels for collected packages: simple
Building wheel for simple (setup.py): started
Building wheel for simple (setup.py): finished with status 'done'
Created wheel for simple: filename=simple-3.0-py3-none-any.whl size=1138 sha256=2a980a802c9d38a24d29aded2dc2df2b080e58370902e5fdf950090ff67aec10
Stored in directory: /tmp/pytest-of-iwienand/pytest-0/test_pip_wheel_success0/workspace/scratch
Successfully built simple
PEP 427 has no specific requirements for the format of the version.
As pip wheel allows to create a wheel with a non-PEP 440 version,
it should also be able to install that same wheel.