On ti, 15 kesä 2021, Petr Viktorin wrote:
On 14. 06. 21 20:09, Alexander Bokovoy wrote:
On ma, 14 kesä 2021, Ben Cotton wrote:
[...]
==== 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.
Then I'd recommend that the project name in dist-info metadata would
be, for example "samba-bindings".
Samba Python bindings have no dist-info metadata. Does it need to? The
bindings are consumed by few projects around Samba but none of them has
anything related on PyPI. What exists on PyPI is either an outdated
stuff without upstream sources or a reference to a similar outdated
stuff, none of which is using Samba Python bindings.
This matters in cases like a pip-installable package declaring a
dependency on Samba bindings: it now can't use `samba` because that
means something else on PyPI.
There are already unrelated projects with Samba name on PyPI. This
change in Fedora guidelines cannot affect those. It cannot also affect
actual use of Samba Python bindings. It looks like there is no real use
of PyPI for our use case either, so why the fuss for this particular
package?
I suspect at best we'd submit a request for exception, if pressed.
I fully agree about not installing Samba itself via pip.
(Also, this is one of the cases that might take a decade -- I'm not
putting pressure on you to implement this, but pointing out a
direction for the future.)
Frankly, I do not see a real use case for what you might see in other
projects. We had a similar issue with FreeIPA and what we provide on
PyPI is a crippled subset of FreeIPA Python modules that mostly does not
use real FreeIPA features. To date, I am not sure it is really bringing
any benefit to us (upstream).
This does not mean the whole effort is useless, not at all. It means, in
my opinion, that proposed guidelines are failing to address real world
use cases present in Fedora. Invalidating these use cases is as bad as
dropping the guidelines' changes in one go. ;)
--
/ 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
