3.17.3 Wheel Filenames for Python 3.x Manylinux

[nwchandler]

Hello.

I have recently discovered an issue when simplejson 3.17.3 is a dependency for an AWS Lambda, which I am attempting to build using AWS SAM. The gist is that SAM is failing to identify an appropriate wheel file; I believe I know why, but I don't know for sure whether this is an issue with simplejson. I'm hoping you can maybe provide some feedback, and I can track the issue down further from there.

SAM CLI assumes that the platform is encoded in the filename, in between the final - and the .whl extension. For example, this is the filename for the manylinux 2010 x86/64 platform in simplejson version 3.17.2: simplejson-3.17.2-cp38-cp38-manylinux2010_x86_64.whl. Version 3.17.2 works just fine, as SAM is able to identify this as compatible with Lambda.

With version 3.17.3, this appears to have changed, and I see from #283 that there were changes in the CI system that went into 3.17.3. Here is a wheel filename for 3.17.3: simplejson-3.17.3-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl. It seems that a handful of platforms are included, with names separated by .'s. Although I don't know for certain that this is not allowed, it does appear to violate the naming conventions in PEP-491. That said, it looks like CI Build Wheel is building these, and since it's maintained by the PyPA, I wouldn't think this would be invalid.

So, ultimately, my question is, do you happen to have any insight into why this name is being used and whether you believe it to be incorrect? I'm not looking for you to review other people's code, but if you're interested in looking at SAM's package management logic, it can be hard to find - to save some time, it is available here.

Thanks!

[etrepum]

I am not an expert in manylinux wheels, I just did my best to follow the CI Build Wheel docs and examples that I could find when I had to port the CI from Travis to GitHub Actions. If you have any insight or even better a patch to fix the distribution for your use case I’d be happy to promptly review and accept it.

[nwchandler]

Thank you for the quick reply. I'll keep researching to see if I can confirm whether the current naming follows standards, and if so, I'll follow up with the AWS SAM folks to fix their current logic. If it's not, I'll try and identify how to change the name and submit a patch PR.

Thanks,
Nick

[etrepum]

Looking more closely it seems that the auditwheel repair step is responsible for this PEP-425 Compressed Tag Sets compliant naming convention. I'm going to close this for now, as it seems that the problem is elsewhere.

[nwchandler]

Thanks for continuing to investigate! I got sidetracked yesterday and was not able to do so.

This absolutely looks like what's going on. I will follow up with the AWS SAM team on this.

[nwchandler]

In case anyone else happens to come across this, it looks like this was actually resolved in version 1.24.0 of the SAM CLI, with this PR. Unfortunately, it turns out that my team and I were testing with an older version of the SAM CLI when we found this issue. Sorry for any confusion here, but just in the event someone else happens upon it, I figured I'd post the resolution.