Pants unable to detect wheel tag

[krawson-bsky]

Describe the bug I'm working with a wheel (attached to bug report) that is built using python 3.6.14 and is converted from an egg for Orekit. After copying the wheel into my repository, pants only recognized the wheel as cp-none-any. At the suggestion in slack, I ran the auditwheel repair job with --plat linux_x86_64 as the desired tag, which updated the tag as desired however pants still threw the same error.

Pants version 2.11

OS debian, inside of a python 3.6.14 docker container

Additional info Debug report: pants_debug_report.txt Pants.toml, BUILD, orekit wheel metadata, pants execution output with debug: pants_bug_report_artifacts.gz

[jsirois]

@krawson-bsky that wheel looks bad still.

From orekit_wheel_metadata.json:

wheel2json 3rdparty/repos/orekit-10.3.1-py36-none-linux_ ...

Those wheel tags are not valid. Is that the wheel tag audit wheel picked?

[krawson-bsky]

If I start with a fresh wheel, and run auditwheel repair --plat linux_x86_64 this is what I get:

root@9c493848ff41:/tmp/output# auditwheel repair --plat linux_x86_64 orekit-10.3.1-py36-cp36-linux_x86_64.whl 
INFO:auditwheel.main_repair:Repairing orekit-10.3.1-py36-cp36-linux_x86_64.whl
INFO:auditwheel.wheeltools:Previous filename tags: linux_x86_64
INFO:auditwheel.wheeltools:No filename tags change needed.
INFO:auditwheel.wheeltools:Previous WHEEL info tags: py36-cp36-linux_x86_64
INFO:auditwheel.wheeltools:No WHEEL info change needed.
INFO:auditwheel.main_repair:
Fixed-up wheel written to /tmp/output/wheelhouse/orekit-10.3.1-py36-cp36-linux_x86_64.whl

[krawson-bsky]

And to answer the question, I ran wheel2json against the repaired wheel that I expected to be tagged as py36-none-linux_x86_64, I didn't try to manually tag the wheel at all

[jsirois]

Ok, that wheel tag still looks bad, but better at least. It must exactly match one of the tags in the Pants error output. I'm pretty sure you want cp36-cp36m-manylinux_2_24_x86_64.

[krawson-bsky]

The closest I can get is py36-cp36-manylinux_2_24_x86_64 which doesn't work. If I do auditwheel repair --help to list the platforms, I only see these tags:

PLATFORMS:
These are the possible target platform tags, as specified by PEP 600.
Note that old, pre-PEP 600 tags are still usable and are listed as aliases
below.
- linux_x86_64
- manylinux_2_5_x86_64 (aliased by manylinux1_x86_64)
- manylinux_2_12_x86_64 (aliased by manylinux2010_x86_64)
- manylinux_2_17_x86_64 (aliased by manylinux2014_x86_64)
- manylinux_2_24_x86_64
- manylinux_2_27_x86_64
- manylinux_2_28_x86_64
- manylinux_2_31_x86_64

[jsirois]

Feel free to just hand rename the wheel. The only internal metadata that won't match is in the WHEEL file under *.dist-info/ and that file is not consulted during a resolve.

[krawson-bsky]

I manually updated the name to orekit-10.3.1-cp36-cp36m-manylinux_2_24_x86_64.whl and still hit the same error in the ticket description.

[jsirois]

Ok @krawson-bsky , the issue here is Pex can build a PEX with a bogus wheel, but then fails to boot that PEX later. It should have the same failure at build time and refuse to build a PEX in the 1st place. Since building the PEX succeeded, Pants cached that. You need to get Pants to ignore the bad cached PEX in order to pick up the now correctly named wheel. The sure fire but last resort way is to rm -r ~/.cache/pants/lmdb_store. That wipes all of the Pants stable cache though, which is unfortunate. Alternatively, if you can modify the requirement string for your dependency on this wheel in any reasonable way, that would trigger re-resolve and a fresh PEX build. You'll also want to kill pantsd after doing this. One way is to rm -r .pids/.

[jsirois]

For example, if your dependency is not already pinned, pin it to orekit==10.3.1.

[krawson-bsky]

We already had the version pinned, but deleting the lmdb_store worked like a charm and I was able to get pants to recognize the whl. Thanks!