<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>Hey Charlie,<br><br><div><div>The full build log for the snap might be more interesting than posting the output from pip in this thread. </div><div><a href="https://launchpadlibrarian.net/643304763/buildlog_snap_ubuntu_focal_amd64_e0fec5d9b363f11b29818f8f9274f735_BUILDING.txt.gz">https://launchpadlibrarian.net/643304763/buildlog_snap_ubuntu_focal_amd64_e0fec5d9b363f11b29818f8f9274f735_BUILDING.txt.gz</a></div><div><br></div><div>I get the feeling that pip says "error" but doesn't mean "fatal error", if such a distinction still exists today. Pip does continue to install CHIRP (using the legacy setup.py which I think will break soon)<br></div><div><br></div><div>Tony<br></div></div><br><p>December 30, 2022 at 8:44 AM, "Charlie Li via chirp_devel" &lt;<a href="mailto:chirp_devel@intrepid.danplanet.com?to=%22Charlie%20Li%20via%20chirp_devel%22%20%3Cchirp_devel%40intrepid.danplanet.com%3E" target="_blank" tabindex="-1">chirp_devel@intrepid.danplanet.com</a>&gt; wrote:</p><blockquote><div>Dan Smith via chirp_devel wrote:</div><blockquote><blockquote><div>Here's what I'm seeing when snapcraft tries to install CHIRP:</div><div> + pip install -U .</div><div> ...</div><div> Building wheels for collected packages: chirp, future, yattag</div><div> ...</div><div>    WARNING: Built wheel for chirp is invalid: Metadata 1.2 mandates PEP 440 version, but 'daily-20221229' is not</div><div> ...</div><div> Failed to build chirp</div></blockquote></blockquote><div><br></div><div>What's in between the first warning and the failure message? Warnings </div><div>are just that, and I've still managed to build sdists and bdists despite </div><div>them.</div><blockquote><blockquote><div>...</div><div>    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</div><div> <a href="https://github.com/pypa/pip/issues/8368" target="_blank">https://github.com/pypa/pip/issues/8368</a></div></blockquote><div><br></div><div> </div><div> 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.</div><div> </div><div> 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 &gt;99%.</div></blockquote><div><br></div><div>Many packages just use &lt;year&gt;.&lt;month&gt;.&lt;day&gt; outright for this reason, </div><div>and it still fits PEP-440.</div><div><br></div><div>-- </div><div>Charlie Li</div><div>…nope, still don't have an exit line.</div><div><br></div><div><br></div><div>_______________________________________________</div><div>chirp_devel mailing list</div><div><a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a></div><div><a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a></div><div>Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a></div></blockquote><div><br></div></body></html>