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