On Mon, Jun 14, 2021 at 3:05 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 14. 06. 21 20:09, Alexander Bokovoy 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.
As long as the RPM package doesn't contain dist-info/egg-info that says "this
is a Python package called samba" (and hence doesn't provide e.g.
python3dist(samba)), this rule does not apply to samba's Python bindings.
This is completely unreasonable. The dist-info/egg-info data of a
Python module is for generating dependencies, not for forcing people
to deal with PyPI.
I reiterate that I did not *ever* envision the Python SIG using the
dependency generator I introduced as a means to act as a gatekeeper
for Python software packaging in Fedora.
--
真実はいつも一つ!/ Always, there's only one truth!