[opensuse-packaging] On Python packages naming
Hi guys, currently most Python packages in the Build Service are inconsistently named. For instance, upstream 'pyenchant' is named python-enchant, 'Cheetah' is named python-cheetah. There are plenty of other examples. I'd like to propose a different scheme (much like our Ruby and Perl packages): * Python application packages are named like $UPSTREAM_NAME * Python libraries are named python-$UPSTREAM_NAME Upstream names means what is found on PyPi (pypi.python.org). PyPi names make the most sense as upstream projects names clash sometimes, PyPI names are unique. Here are some examples: * 'bpython' stay 'bpython' as it is an app * 'IPython' would become 'ipython', as this is the PyPi package name (not the app name) * 'python-enchant' becomes 'python-pyenchant' * 'python-cheetah' becomes 'python-Cheetah' * 'python-twitter' becomes 'python-python-twitter' While the last example doesn't look too fancy, this generally has huge advantages. First of all users now have a clue what to search for. More importantly, there's a clear dependency between package name and upstream name, which helps a lot for automatic spec file generation (BuildRequires/Requires). For some newer packages, this seem to have happened already. I'd suggest that when a new upstream version for a 'broken' package is available, an entirely new package (with correct name) is added and the old one obsoleted. Python applications should also Provide: python-$UPSTREAM_NAME to be compatible with the above scheme. As an example, I added the package 'python-pyenchant' to devel:languages:python, that obsoletes/provides the older 'python-enchant'. -------------------------------------------------------------------------------- Regarding BuildRequires/Requires, we may even want to adopt the Perl package scheme. For the package 'python-py2pack' this would look like: BuildRequires: python-devel BuildRequires: python(Jinja2) >= 2.5 BuildRequires: python(argparse) Requires: python(Jinja2) >= 2.5 Requires: python(argparse) This needs some tool support, off course. -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
On Friday, April 15, 2011 03:46:34 PM Sascha Peilicke wrote:
Hi guys,
currently most Python packages in the Build Service are inconsistently named. For instance, upstream 'pyenchant' is named python-enchant, 'Cheetah' is named python-cheetah. There are plenty of other examples. I'd like to propose a different scheme (much like our Ruby and Perl packages):
* Python application packages are named like $UPSTREAM_NAME * Python libraries are named python-$UPSTREAM_NAME
Sascha, what are other projects like Debian, Ubuntu and Fedora doing? Let's talk with other rpm based distros on whether we can implement the same scheme - this make cross-distribution building much saner... The proposal looks sane to me, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday, April 15, 2011 04:13:00 PM Andreas Jaeger wrote:
On Friday, April 15, 2011 03:46:34 PM Sascha Peilicke wrote:
Hi guys,
currently most Python packages in the Build Service are inconsistently named. For instance, upstream 'pyenchant' is named python-enchant, 'Cheetah' is named python-cheetah. There are plenty of other examples. I'd like to propose a different scheme (much like our Ruby and Perl packages):
* Python application packages are named like $UPSTREAM_NAME * Python libraries are named python-$UPSTREAM_NAME
Sascha, what are other projects like Debian, Ubuntu and Fedora doing? Let's talk with other rpm based distros on whether we can implement the same scheme - this make cross-distribution building much saner...
This is a good idea, python-python-twitter looks really counter-intuitive though, maybe there should be an exception if the package already has a python- prefix. Regards. -- İsmail Dönmez - openSUSE Booster SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday 15 April 2011 16:13:49 İsmail Dönmez wrote:
On Friday, April 15, 2011 04:13:00 PM Andreas Jaeger wrote:
On Friday, April 15, 2011 03:46:34 PM Sascha Peilicke wrote:
Hi guys,
currently most Python packages in the Build Service are inconsistently named. For instance, upstream 'pyenchant' is named python-enchant, 'Cheetah' is named python-cheetah. There are plenty of other examples. I'd like to propose a different scheme (much like our Ruby and Perl packages):
* Python application packages are named like $UPSTREAM_NAME * Python libraries are named python-$UPSTREAM_NAME
Sascha, what are other projects like Debian, Ubuntu and Fedora doing? Let's talk with other rpm based distros on whether we can implement the same scheme - this make cross-distribution building much saner...
This is a good idea, python-python-twitter looks really counter-intuitive though, maybe there should be an exception if the package already has a python- prefix.
Yeah, if it's 'python-' we may want to drop that prefix. This seems to be the case for our Perl and Ruby packages, too. -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
Dne 15.4.2011 17:02, Sascha Peilicke napsal(a):
On Friday 15 April 2011 16:13:49 İsmail Dönmez wrote:
On Friday, April 15, 2011 04:13:00 PM Andreas Jaeger wrote:
On Friday, April 15, 2011 03:46:34 PM Sascha Peilicke wrote:
Hi guys,
currently most Python packages in the Build Service are inconsistently named. For instance, upstream 'pyenchant' is named python-enchant, 'Cheetah' is named python-cheetah. There are plenty of other examples. I'd like to propose a different scheme (much like our Ruby and Perl packages):
* Python application packages are named like $UPSTREAM_NAME * Python libraries are named python-$UPSTREAM_NAME
Sascha, what are other projects like Debian, Ubuntu and Fedora doing? Let's talk with other rpm based distros on whether we can implement the same scheme - this make cross-distribution building much saner...
This is a good idea, python-python-twitter looks really counter-intuitive though, maybe there should be an exception if the package already has a python- prefix.
Yeah, if it's 'python-' we may want to drop that prefix. This seems to be the case for our Perl and Ruby packages, too.
+1 to this -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/15/2011 03:46 PM, Sascha Peilicke wrote:
* 'python-enchant' becomes 'python-pyenchant' * 'python-cheetah' becomes 'python-Cheetah' * 'python-twitter' becomes 'python-python-twitter'
Wouldn't a little flexibility in the python naming convention be in order, pyenchant is obvious from the name that it's a python app whereas Cheetah needs the python prefix to identify it as a python app. If applications or libraries start with py they can retain the upstream name with no ill effect. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday 15 April 2011 16:47:33 Dave Plater wrote:
On 04/15/2011 03:46 PM, Sascha Peilicke wrote:
* 'python-enchant' becomes 'python-pyenchant' * 'python-cheetah' becomes 'python-Cheetah' * 'python-twitter' becomes 'python-python-twitter'
Wouldn't a little flexibility in the python naming convention be in order, pyenchant is obvious from the name that it's a python app whereas Cheetah needs the python prefix to identify it as a python app. If applications or libraries start with py they can retain the upstream name with no ill effect.
Just search for "markdown" on PyPI and tell me which one we package in "python-markdown" w/o looking at the source tarball. There are other examples, this ambiguity is what I want to have avoided. It's not about what a human may be able to grasp from a package name, it's what scripts are able to do. From our current, lazy package names you can't deduce what they provide. My example package 'python-enchant' is a perfect example, for one or another reason it also provides 'PyEnchant', which is a name you may find on the upstream web page. Neither this nor the package name have anything to do with 'pyenchant', the result you would find by search PyPi (or using pip, easy_install, ...). And now consider this packages has a requires on pyenchant in it's setup.py file. How do you translate that into a BuildRequires/Requires for our existing packages? -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
On Friday 15 April 2011 17:10:00 Sascha Peilicke wrote:
On Friday 15 April 2011 16:47:33 Dave Plater wrote:
On 04/15/2011 03:46 PM, Sascha Peilicke wrote:
* 'python-enchant' becomes 'python-pyenchant' * 'python-cheetah' becomes 'python-Cheetah' * 'python-twitter' becomes 'python-python-twitter'
Wouldn't a little flexibility in the python naming convention be in order, pyenchant is obvious from the name that it's a python app whereas Cheetah needs the python prefix to identify it as a python app. If applications or libraries start with py they can retain the upstream name with no ill effect.
Just search for "markdown" on PyPI and tell me which one we package in "python-markdown" w/o looking at the source tarball. There are other examples, this ambiguity is what I want to have avoided. It's not about what a human may be able to grasp from a package name, it's what scripts are able to do. From our current, lazy package names you can't deduce what they provide.
My example package 'python-enchant' is a perfect example, for one or another reason it also provides 'PyEnchant', which is a name you may find on the upstream web page. Neither this nor the package name have anything to do with 'pyenchant', the result you would find by search PyPi (or using pip, easy_install, ...).
And now consider this packages has a requires on pyenchant in it's setup.py file. How do you translate that into a BuildRequires/Requires for our existing packages? Typed to fast, I meant "And now consider another package that has a requires ..." -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
On 04/15/2011 05:10 PM, Sascha Peilicke wrote:
Just search for "markdown" on PyPI and tell me which one we package in "python-markdown" w/o looking at the source tarball. There are other examples, this ambiguity is what I want to have avoided. It's not about what a human may be able to grasp from a package name, it's what scripts are able to do. From our current, lazy package names you can't deduce what they provide.
It's nice to know what the upstream name is and I understand your reasoning why python-pyenchant is the right name.
My example package 'python-enchant' is a perfect example, for one or another reason it also provides 'PyEnchant', which is a name you may find on the upstream web page. Neither this nor the package name have anything to do with 'pyenchant', the result you would find by search PyPi (or using pip, easy_install, ...).
And now consider this packages has a requires on pyenchant in it's setup.py file. How do you translate that into a BuildRequires/Requires for our existing packages?
If it provides pyenchant that will satisfy rpm and the files provided by python-pyenchant are the same no matter how it's built so a BuildRequires: pyenchant will pull in the necessary files but for a manual Requires: I'd put python-pyenchant. For cross distro compatability, which is a territory I'm only starting to explore, a universal Provides: pyenchant helps a lot. Unfortunately that doesn't seem to be the case, Fedora's python-enchant and Mandriva's package python-enchant provide PyEnchant and their packages are both named the same as our original package name. There should be some agreement across distributions about providing the correct upstream name which PyEnchant isn't but in a not so ideal world our package should provide it too. All said and done, I get the impression that the developers of these packages are targeting msWindows and Mac.
-- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (5)
-
Andreas Jaeger -
Dave Plater -
İsmail Dönmez -
Jan Matejek -
Sascha Peilicke