
Unveiling Poetry 2.0: A Major Leap for Python Dependency Management
The Poetry team has launched Poetry 2.0.0, revolutionizing Python project dependency management with new features and enhancements. This release not only aligns with PEP 621 but also introduces signif...
https://news.lavx.hu/article/unveiling-poetry-2-0-a-major-leap-for-python-dependency-management
Okej, sprecyzujmy coś. #PEP621 to nie jest końcowy standard, który unifikuje systemy budowania #PEP517.
Tak, to dobry standard. Tak, dostarcza jednolitą specyfikację dla metadanych paczek. Jednakże, pomijając już opcję "dynamicznych metadanych", które zależą od implementacji, to PEP 621 nie specyfikuje, w jaki sposób mają tworzone być paczki źródłowe albo binarne — na przykład, skąd należy brać kod Pythona do paczki. To wszystko jest nadal wyborem konkretnej implementacji.
Dobra wiadomość: jeżeli paczka jest prosta jak konstrukcja cepa, i w miarę typowa, to najpewniej można w niej podmienić system budowania na inny zgodny z PEP 621, i będzie działać. Zła wiadomość: nie ma żadnej gwarancji. Rezultatem może być wszystko, od jakiś minimalnych różnic, do całkowicie dysfunkcyjnych paczek.
Okay, let's get things clear. #PEP621 isn't the ultimate standard to unify #PEP517 build systems.
Yes, it's a good standard. Yes, it specifies a uniform format for specifying baseline package metadata. However, besides allowing for implementation-defined dynamic metadata, it does not specify anything related to how the source distributions and wheels are actually created — where to take Python packages from, for example. All these things are still implementation-defined.
Good news is, if your package has a trivial and common enough layout, then you can probably switch between different PEP 621-compliant build systems and things will just work. Bad news is, there's no guarantee of that. You may as well get anything from slight packaging differences to completely dysfunctional wheels and/or sdists.