On Thu, Mar 28, 2013 at 12:20 PM, Michael Schwendt <mschwendt@xxxxxxxxx> wrote:
> On Thu, 28 Mar 2013 05:47:37 -0400 (EDT), Bohuslav Kabrda wrote:
>
>> Hi all,
>> so after spending some months with Python packaging, I came to think that the naming has to be standardized better.
Thanks for this follow-up! The feature page, I created, is somehow
stalled, because it seems the added complexity of python naming didn't
qualify to improve the current "it's working fine as it is now - just
search where the package you are looking for is packaged" situation...
Count me in for creating a new python packaging naming guideline.
>> Problem 1:
>> The naming guidelines say, that if there is "py" or "Py" in package name, you _can_ use that name for a package, otherwise use python-{name} [1]. So if I'm trying to install "pygments", I just try "pygments", but whoops - it's named python-pygments. How could I tell?
>>
>
> "yum search pygments" or the equivalent in a graphical package tool.
> Also "yum list py\*|grep pygments" (or grep -i …) would find it.
>
> Trial-and-error guessing of package names isn't practical. Searching
> manually in possibly alphabetically sorted lists of thousands of packages
> isn't practical either.
"Isn't practical" is a perfect reason to improve it with a new python
package naming proposal.
> The uppercase "Py" is a good example. In bugzilla, uppercase package names
> are listed before lowercase package names. Nasty. A "yum search" and
> "yum list py\*" is case-insensitive, however.
>
>> Problem 2:
>> If I install "PyYaml" (this time I was lucky and guessed correctly), then it's confusing that I have to install python3-PyYaml. Both should be prefixed "python[possibly 3]-", or none of them.
>>
>
> When and how to apply such prefixes has confused packagers/reviewers before:
>
> # yum list django\*|grep ^django|wc -l
> 5
> # yum list python-django\*|grep ^python-django|wc -l
> 70
>
> Some of the django-* packages have been renamed, but this shows that guessing
> prefixes wouldn't work well either.
I'd consider this as the same problem like above. It's simply
inconsistent and a python prefix as a must-have would be one/the
solution.
>> So my proposal would be:
>> Let's make it mandatory for all the Python package names to be prefixed with python-/python3-. If the upstream name already starts with "python-", then let's use that (possibly inserting the "3").
>>
>
> Do you propose it just because of the package searching and installation
> attempts you've described? What other benefits would there be? Currently,
> all Python packages should start with "py" (or "Py"), except if it's a package
> that doesn't extend Python but some program (e.g. claws-mail-plugins-python).
I'd further prefer to have an dependent naming from the underlying
interpreter in the python package name e.g. python2-foo and
python3-foo while python-foo must contain the module foo, that is
build with the current default interpreter. That can be archived, when
adding some %{python_provide}-like macros, that decides in all
python*-foo packages, which one now provides the python-foo virtual
provides, but further complicates the python packaging to some
extend...
That's why I want to further propose:
- A module must contain the name of the underlying python interpreter,
e.g. python3-foo, sssd-python3.
- A macro will be created, that decides on build time, if the
corresponding package provides the python-foo or sssd-python package
with the default interpreter.
such as %python_provides $name $interpreter, e.g. %python_provides
sssd-python python3
Drawback:
- There is no possibility to add a python-foo package, that provides
the "foo" package, built with the current default interpreter. Maybe
we should add an exception for that?
I'd prefer to forbid the python-foo naming completely...
Why to be independent of the python interpreter?
This will create some (not to say much) work to set this new
guidelines in place, but it will pay out in the long term, when
further python interpreter migrations might happen.
Comments? Thoughts?
Greetings,
Tom
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
