Extensions do not return a version if packaged with the latest version of wheel

[noelbundick]

Describe the bug
Extensions do not return a version if packaged with the latest version of wheel. I noticed that the extension command module was pinned to 0.30.0 in #6164, but the version returns null if extensions were built with the latest wheel

Ex: I build an extension using the VSTS Python build tools, which uses the Build Python wheels task. This appears to use the latest version of wheel, or at least one 0.31.0 or newer. This reproduces locally if using 0.31.1, but my older builds that were 0.30.0 properly return a version

On latest, when the wheel is built, there is no metadata.json in the noelbundick-0.0.x.dist-info folder, and as a result, I get the following output when I run az extension list:

[
  {
    "extensionType": "whl",
    "name": "noelbundick",
    "version": null
  }
]

To Reproduce

1. Install my extension via

az extension add --source https://github.com/noelbundick/azure-cli-extension-noelbundick/releases/download/v0.0.5/noelbundick-0.0.5-py2.py3-none-any.whl

2. List the files that were installed, noting that metadata.json is not present

ls ~/.azure/cliextensions/noelbundick/noelbundick-0.0.5.dist-info

3. List installed extensions

az extension list

observe that the version is null

Expected behavior
I expect the version in the output to match the version contained in my setup.py (in this case, 0.0.5)

Environment summary
apt-get / 2.0.33 / Ubuntu 18.04 / WSL

[williexu]

@noelbundick This is due to: pypa/wheel#195, which removed the metadata.json from generated files.

For now, we expect extensions to be built using either 0.29.0 or 0.30.0

[noelbundick]

@williexu thanks for merging the docs PR!

Would you be open to a PR that pulls the version from *.dist-info/METADATA instead of the now-gone *.dist-info/metadata.json? That should cover both the pre 0.31.0 versions as well as latest

I'm new-ish to Python - so I'm unsure if I'm going to run into trouble there, or if that's a pretty safe change to investigate

[williexu]

@noelbundick that should be fine, feel free to open a PR

[tjprescott]

I believe this is fixed. If not, please open a new issue.