[chirp_devel] Here we go...

[Charlie Li]

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.

-- 
Charlie Li
…nope, still don't have an exit line.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20221230/8db3597a/attachment-0001.bin