On 15. 06. 21 13:48, Neal Gompa wrote:
On Tue, Jun 15, 2021 at 6:50 AM Petr Viktorin <pviktori@xxxxxxxxxx> wrote:
Hi Neal,
We had this conversation in the past (and you can see it in the change).
I don't think I can convince you, but I'll reiterate since it's new for
devel@.
Unlike the "mandatory tests" issue elsewhere in this thread, using the
PyPI namespace is the main point of the change. I can't take it out.
On 15. 06. 21 2:11, Neal Gompa wrote:
On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer <gordon.messmer@xxxxxxxxx> wrote:
On 6/14/21 1:53 PM, Neal Gompa wrote:
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 don't think we can reasonably separate the two.
https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
(I believe this is the "namespace" issue mentioned in the proposed change.)
You can. When it comes to distribution packages, we can maintain
consistency of the package names referenced within the distribution.
The point of this was to be able to use the names Python packages call
themselves for dependencies. PyPI is merely a distribution center for
such things. Fedora is another distribution center for such things.
You can only separate the namespaces if you sacrifice interoberability,
i.e. allowing pip-installable packages to depend on Fedora packages.
It turns out you can already do that (venv --system-site-packages), and
users expect that dist-info project names use the PyPI namespace. This
is a current problem that we need to solve.
There are other (harder) solutions for the issue than reusing the PyPI
namespace in Fedora, but why should we bother with them? There already
is an ecosystem-wide namespace; why should we add a Fedora-specific one?
(Or a Linux-distro-specific one, if we're interested in cross-distro
collaboration.)
You seem to assume that registering/blocking a name on PyPI is hard.
I say it is not and I am willing to do it for packagers who need it.
(And to mitigate the bus factor, I'll make it a responsibility of Red
Hat's python-maint team.)
It's not terribly different from how organizations may have private
Python package indexes that may use whatever names they want for
Python software they build and release.
I agree, in fact, I think Fedora's problems here are a subset of the
problems the private organizations have: if issues of proprietary corps
are solved, we can use the solution as well. (However, it'll need more
work than is necessary for Fedora/FOSS needs, so I don't want to drive
the effort.)
BUT, if the issues are solved, it'll likely be through namespacing: we'd
need to prefix our names with `fedora-` or `fedora:`. I still think it
is better for Fedora to reuse the public PyPI namespace rather than
start its own.
As long as you don't make packagers deal with it, I'm fine with it.
I'm okay with the PyPI contract as long as you don't make me or any
other Fedora packager specifically deal with it. And I strongly
suspect you're going to want automation in the future, but that choice
is up to you.
When packaging something that isn't on PyPI, you can let me know (on
python-devel@xxxxxxxxxxxxxxxxxxxxxxx ) and I'll get the name blocked. I
expect this to be rare enough to not need automation.
If the name *conflicts* with something on PyPI, then also let me know.
Dealing with that issue might be more difficult, and it might involve
you more. Still, this situation is confusing for users, so I think it's
fair to want to solve it.
(And again, I'm not expecting existing packages to do this *right* now.)
_______________________________________________
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
