On ma, 14 kesä 2021, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x == Summary == The Python Packaging guidelines will be rewritten, with the major changes being '''PyPI parity''' and usage of '''upstream metadata'''. A new set of macros, {{package|pyproject-rpm-macros}}, written in mind with the new guidelines and with upstream best practices, are documented in the new guidelines as practical examples. The older (a.k.a. "201x-era") Python Packaging guidelines will remain in effect as an option (until retired by another Fedora Change). == Owner == * Name: [[User:pviktori| Petr Viktorin]] ** Email: pviktori@xxxxxxxxxx * Name: [[SIGs/Python| Python SIG]] ** Email: python-devel@xxxxxxxxxxxxxxxxxxxxxxx == Detailed Description == The proposed new Python packaging guidelines are available at this Pull request: https://pagure.io/packaging-committee/pull-request/1072 A rendered preview (which might be deleted by the time you read this) is at: http://100.26.217.43/packaging-committee-pr1072/packaging-guidelines/Python/ === Not removing older guidelines === The current ("201x-era") guidelines will stay in effect as an option for packages that haven't migrated yet or those that cannot follow the new guidelines for whatever unforeseen reason. They will be retired in another Fedora Change, some time after the vast majority of Python packages follow the new guidelines and there are no known blockers for the remaining ones. There's no rush; it might well take a decade. === Guideline Changes === See [https://hackmd.io/@python-maint/rJmQQc4DP an external document] for a detailed list of changes to '''MUST'''/'''SHOULD''' rules. The major ones are listed here: ==== Requiring python3-devel ==== All packages that use Python at run- or build-time will need to BuildRequire {{package|python3-devel}}. This package brings the necessary macros and settings, and it will enable automated or manual checks. (For example, Python maintainers use this requirement to list packages that use Python in some way and might be affected by planned changes.) ==== PyPI Parity ==== Machine-readable metadata (''distribution'' names in <code>dist-info</code> directories on disk and the corresponding <code>python3.Xdist(foo)</code> RPM provides) will match the Python Package Index (PyPI). This solves a ''namespace'' issue. Python packaging tools use a flat namespace, and PyPI is ''the'' place where open-source Python packages are generally published, so users and tools assume a package called <code>requests</code> is whatever <code>requests</code> means on PyPI. While this is not ideal (especially for private packages), it makes sense for Fedora to align with the PyPI namespace. Note that Fedora package names are not affected – just the Python packaging metadata on disk and virtual RPM Provides generated from it. The new guidelines cover what to do for packages that cannot be registered on PyPI. The Change owner is prepared to help with PyPI registration. Note that names found in Fedora but not on PyPI [https://github.com/pypa/pypi-support/issues/355 have been reserved on PyPI] to avoid being taken by unrelated projects.
samba has extensive Python C bindings but does not use PyPI at all. We don't want to, we don't need to, it is technically not possible without building Samba from scratch and it would not make it usable for PIP install without a stricter coordination of the non-Python dependencies -- that's what Linux distributions do. In addition, 'samba' name is taken by an unrelated package on PyPI which was not updated since 2019. For us this namespacing enforcement would only be a problem.
=== Burdening packagers === [https://lists.fedoraproject.org/archives/list/python-devel@xxxxxxxxxxxxxxxxxxxxxxx/message/IYBF5GX6HVQYPC5EJ6HVK7GJHAIKHVBK/ Neal] does “not necessarily disagree that PyPI and Fedora pythonXdist() names should match, but [he disagrees] on burdening packagers with this.” However, actually pushing a package to PyPI (and maintaining it there) is not necessary. The minimal-effort solution is to ''reserve'' the name on PyPI so that a conflicting package can not be created there. The author of this change is willing to do this work for all Python packages whose upstream is not on PyPI; packagers need to send a request to the Python SIG list. If something happens to me, Red Hat's python-maint team is also ready to do this, and in the event of catastrophic management change, PyPI maintainers can be e-mailed directly. This is all described in the new guidelines (see the ''PyPI parity'' section). The new guidelines discourage the minimal-effort solution because it is suboptimal ''for users'' (and for the wider Python ecosystem).
In case of Samba I would argue that going with anything but minimal-effort is actually suboptimal to users.
(It was further suggested that the registration process should be ''automatic'' to minimize burden on packagers. It will be automated if it's too much for humans to handle, but we expect there won't be enough requests to make automation worth it.) === Conditioning names on PyPI === Neal also [https://lists.fedoraproject.org/archives/list/python-devel@xxxxxxxxxxxxxxxxxxxxxxx/message/IYBF5GX6HVQYPC5EJ6HVK7GJHAIKHVBK/ fundamentally disagrees] “on conditioning those names on PyPI, because frankly no other ecosystem in Fedora works that way. Not Rust, not Go, not Perl, not OCaml, not anything.” It's true that no other ecosystem in Fedora does this, but the author of this change believes that they should: if the ecosystem uses a flat namespace of dependencies, its Fedora packages ''should'' use the ecosystem-wide namespace rather than a Fedora-specific one. RPM predates global per-ecosystem directories of free/open software, but they are here and users (at least those affected by these issues) are used to them. For Python specifically, PyPI is already a de-facto standard: if you see a name in <code>install_requires</code> in <code>setup.py</code> of some random upstream project you want to package, you can assume that it's the PyPI name. It is in the best interest of Fedora's users to use PyPI names for dependency resolution. == Benefit to Fedora == The new packaging guidelines should encourage sharing packaging work with upstream developers (and through them, with other distros). Hopefully, they'll also free up some packagers' time. PyPI parity will hopefully enable automated ways of mixing Fedora packages with upstream ones. The updated examples and notes will be more useful to today's packagers. The older (a.k.a. "201x-era") Python Packaging guidelines only cover projects that use `setup.py`-based installation (via `setuptools` or `distutils`). The new guidelines and macros support more "build backends" (such as `setup.py`-less `setuptools`, `poetry`, `flit` or others) transparently via [https://www.python.org/dev/peps/pep-0517/ PEP 517] (and they continue to work with projects that use `setup.py` to install). == Scope == * Policies and guidelines: https://pagure.io/packaging-committee/pull-request/1072 * Proposal owners: ** Make {{package|python3-devel}} require {{package|pyproject-rpm-macros}} ** Remove ''provisional'' status from {{package|pyproject-rpm-macros}}; release & package version 1.0. ** Handle PyPI name registration/reservation requests from other packagers. * Other developers: Maintainers of packages that use Python should gradually switch to the new guidelines * Release engineering: https://pagure.io/releng/issue/10164 * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == None expected. Any compatibility impact on individual packages would be a bug. == How To Test == If you maintain a package that uses Python, try to follow the new guidelines. Any major omission or ambiguity is a bug. (Minor/unique cases should be discussed on the [mailto:python-devel@xxxxxxxxxxxxxxxxxxxxxxx Pytohn SIG list] instead; the document is already quite long.) Until this change proposal is approved and enabled, you'll need to BuildRequire `pyproject-rpm-macros` to have the new macros available. Updated packages should be tested normally, as with any other package update. == User Experience == No direct impact on end users. == Dependencies == PyPI maintainers [https://github.com/pypa/pypi-support/issues/355 are aware] of the general direction the Guidelines, and have been supportive. == Contingency Plan == * Contingency mechanism: Revert to the older guidelines * Contingency deadline: N/A (Any time until old guidelines are retired, in a separate Change) * Blocks release? No == Documentation == The new guidelines are the documentation. See ''Detailed Description'' above for links. == Release Notes == Fedora's Python Packaging guidelines have been rewritten to align with modern Python packaging practices and better integrate with the wider Python ecosystem (specifically, the Python Package Index). -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
