Dan Smith via chirp_devel wrote:
Here's what I'm seeing when snapcraft tries to install CHIRP:
- pip install -U .
... Building wheels for collected packages: chirp, future, yattag ... WARNING: Built wheel for chirp is invalid: Metadata 1.2 mandates PEP 440 version, but 'daily-20221229' is not ... Failed to build chirp
What's in between the first warning and the failure message? Warnings are just that, and I've still managed to build sdists and bdists despite them.
... DEPRECATION: chirp was installed using the legacy 'setup.py install' method, because a wheel could not be built for it. pip 23.1 will enforce this behaviour change. A possible replacement is to fix the wheel build issue reported above. Discussion can be found at https://github.com/pypa/pip/issues/8368
I don't really care that python packaging people think that I should use a version number of the format they chose. It's an application, not a library, built by date, and without any semver guarantees.
If this becomes a problem then the non-bundled version will need to use a different version from other things, like 1.0.20221225 or something, but until and unless that becomes a hard requirement I don't think it'll be doing anyone any good to be confusingly different. As noted before, 98% of the users consume the bundled builds, and with as many people are using the flatpak type builds (which I'd put in a similar category), that's probably >99%.
Many packages just use <year>.<month>.<day> outright for this reason, and it still fits PEP-440.