Convert non-pure python wheels

[analog-cbarber]

Support the conversion of non pure python wheels

[analog-cbarber]

Some issues:

• need to correctly set arch in conda package
• need to correctly format name of conda package
• how to test? Probably will have differences in binaries with official conda packages that are compiled from scratch.

[analog-cbarber]

Pypi wheels encode platform dependencies in the platform compatibility tag, but there isn't really any all encompassing standard that enumerates the possibilities. We can at least handle common cases for macos and windows. Linux is complicated by the need to specify runtime libc dependencies, which might need to be reflected as an additional dependency in resulting conda package. It is possible that this might not be feasible in all cases.

https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/

[analog-cbarber]

Will need to add appropriate python_abi dependency if abi tag is present.

Looked at the generated index.json for mypy 1.9.0 for linux-64:

{
  "arch": "x86_64",
  "build": "py39hd1e30aa_0",
  "build_number": 0,
  "depends": [
    "libgcc-ng >=12",
    "mypy_extensions >=1.0.0",
    "psutil >=4.0",
    "python >=3.9,<3.10.0a0",
    "python_abi 3.9.* *_cp39",
    "tomli >=1.1.0",
    "typing_extensions >=4.1.0"
  ],
  "license": "MIT",
  "license_family": "MIT",
  "name": "mypy",
  "platform": "linux",
  "subdir": "linux-64",
  "timestamp": 1709935040390,
  "version": "1.9.0"
}

So you can see that it adds the dependencies that were not present in the wheel:

    "libgcc-ng >=12",
    "python >=3.9,<3.10.0a0",
    "python_abi 3.9.* *_cp39",

Also because the noarch key is not python, then the conda installer will not provide any special support for the site-packages/ so the distribution puts contents explicitly in lib/python3.9/site-packages.