I feel this is more nit-picking, but I'm currently working on packaging the following items (python/zope names) and need some direction:
zc.buildout zope.proxy ZConfig zdaemon zope.testing ZODB3
I haven't exactly liked the current naming conventions, as they leave way too much variation while still being "acceptable". E.g., a package I have already done, pysvn, could have been named "python-pysvn" or "pysvn". If it had been used as "import svn", I would have no problems calling it "python-svn", as that would denote that it is a python package having something to do with SVN (since SVN is already a well-known entity), but upstream calls itself "pysvn" while also using that as the python package name, so calling it "python-pysvn" seemed redundant. However, with the above, there seems to be more ambiguity.
Adding to my naming troubles, there is already a package for zope.interface, which is a dependency of ZODB3, and it's name is python-zope-interface. The problem I am having is that it seems to me that if an entity is fairly standalone, i.e. there is no ambiguity whether or not it is a python (or any other language) library/application, that the "python" prefix would be dropped. We don't currently call TurboGears, "python-TurboGears" (yet there are other turbo-related libs that follow the python prefix scheme, e.g. python-turbokid and python-turbocheeta).
Really, I'm asking the Python consuming portion of the Fedora Community what they would rather see. I can also take this up on the packaging list, but thought I'd ask here first because potentially it's the people on this list that would be consuming these packages.
Would it be:
python-zc-buildout python-zope-proxy python-ZConfig python-zdaemon python-zope-testing python-ZODB3 python-zope (thrown in to add contrast, and I'm still working on packaging it...)
Or the above without the prefix?
It seems to me that there should be a more firm guideline that takes into account python applications, python only frameworks/libs, and python lib ports (these seem to be the bulk of how a name would be determined).
--Tim _______________________________________________________________________ / Much of the excitement we get out of our work is that we don't really \ | know what we are doing. | \ -- E. Dijkstra / ----------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).
Timothy Selivanow wrote:
I feel this is more nit-picking, but I'm currently working on packaging the following items (python/zope names) and need some direction:
zc.buildout zope.proxy ZConfig zdaemon zope.testing ZODB3
I haven't exactly liked the current naming conventions, as they leave way too much variation while still being "acceptable". E.g., a package I have already done, pysvn, could have been named "python-pysvn" or "pysvn". If it had been used as "import svn", I would have no problems calling it "python-svn", as that would denote that it is a python package having something to do with SVN (since SVN is already a well-known entity), but upstream calls itself "pysvn" while also using that as the python package name, so calling it "python-pysvn" seemed redundant. However, with the above, there seems to be more ambiguity.
Adding to my naming troubles, there is already a package for zope.interface, which is a dependency of ZODB3, and it's name is python-zope-interface. The problem I am having is that it seems to me that if an entity is fairly standalone, i.e. there is no ambiguity whether or not it is a python (or any other language) library/application, that the "python" prefix would be dropped. We don't currently call TurboGears, "python-TurboGears" (yet there are other turbo-related libs that follow the python prefix scheme, e.g. python-turbokid and python-turbocheeta).
TurboGears was built before the Guideline.
(Django, OTOH, was built in violation of the guidelines and I didn't get to the review bug in time to get it changed)
Really, I'm asking the Python consuming portion of the Fedora Community what they would rather see. I can also take this up on the packaging list, but thought I'd ask here first because potentially it's the people on this list that would be consuming these packages.
Would it be:
python-zc-buildout python-zope-proxy python-ZConfig python-zdaemon python-zope-testing python-ZODB3 python-zope (thrown in to add contrast, and I'm still working on packaging it...)
Or the above without the prefix?
It seems to me that there should be a more firm guideline that takes into account python applications, python only frameworks/libs, and python lib ports (these seem to be the bulk of how a name would be determined).
An application doesn't need to be prefixed with python-.
The question is, of course, if something like gourmet which has a module... but that module really just exists to be imported by the program should be gourmet or python-gourmet. I wouldn't stop someone from going either way with this.
Other than that, bit... python libs and python lib ports should both be prefixed with python-. A python framework should be prefixed with python- as well but the definition of framework is a bit ambiguous: zope can run standalone and therefore could be considered an application while TurboGears cannot run until someone creates an application that imports it, therefore it should definitely have been named python-turbogears.
So in your list, you need to decide if it's an application, an application which happens to have a module to support its functionality, or if it's a module that people are expected to use in their programs. If the latter, you are most likely going to want a python- prefix.... although you might want to have a subpackage for the application in corner cases where it's equally likely that someone would import a certain module and that someone else would run the program.
-Toshio
On Thu, 2008-04-24 at 16:21 -0700, Toshio Kuratomi wrote:
Other than that, bit... python libs and python lib ports should both be prefixed with python-. A python framework should be prefixed with python- as well but the definition of framework is a bit ambiguous: zope can run standalone and therefore could be considered an application while TurboGears cannot run until someone creates an application that imports it, therefore it should definitely have been named python-turbogears.
So, under that logic, I should have named pysvn python-pysvn? That seems a bit redundant to me, but I'm willing to play along if that is the consensus. From now on, I'll make an effort to name things that way, unless I hear a better reason not to (name space pollution, lib-{package} naming in other distros, other historical reason that I'm not aware of or privy to...).
If this is The Way, it should be updated on the wiki so other (future) maintainers can avoid the ambiguity. Yes, I've volunteered to make the change (or propose it to Packaging Committee) as long as there is sufficient consensus, or however the Python SIG is making decisions. That is unless someone with more tenure would be more applicable in this case.
--Tim _____________________________________________________________________________ < "But what we need to know is, do people want nasally-insertable computers?" > ----------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).
Timothy Selivanow wrote:
On Thu, 2008-04-24 at 16:21 -0700, Toshio Kuratomi wrote:
Other than that, bit... python libs and python lib ports should both be prefixed with python-. A python framework should be prefixed with python- as well but the definition of framework is a bit ambiguous: zope can run standalone and therefore could be considered an application while TurboGears cannot run until someone creates an application that imports it, therefore it should definitely have been named python-turbogears.
So, under that logic, I should have named pysvn python-pysvn? That seems a bit redundant to me, but I'm willing to play along if that is the consensus.
Yeah... but there is a specific exception in the guidelines for packages which start with 'py'. scop talked about having that exception removed (old packages grandfathered) but it never reached the proposal stage.
If this is The Way, it should be updated on the wiki so other (future) maintainers can avoid the ambiguity. Yes, I've volunteered to make the change (or propose it to Packaging Committee) as long as there is sufficient consensus, or however the Python SIG is making decisions. That is unless someone with more tenure would be more applicable in this case.
If the wiki isn't clear, definitely draft better wording and propose it to the Packaging Committee.
-Toshio
On Fri, Apr 25, 2008 at 09:02:38AM -0700, Timothy Selivanow wrote:
So, under that logic, I should have named pysvn python-pysvn? That seems a bit redundant to me, but I'm willing to play along if that is the consensus. From now on, I'll make an effort to name things that way, unless I hear a better reason not to (name space pollution, lib-{package} naming in other distros, other historical reason that I'm not aware of or privy to...).
I agree that python-pysvn seems redundant, but that is the fault of the project creators, and is probably not up to packagers to correct. Naming a python package with "py" in the name is redundant itself. But, since you're going to have to "import pysvn", you might was well be installing python-pysvn.
On Fri, 2008-04-25 at 10:25 -0700, Kyle VanderBeek wrote:
On Fri, Apr 25, 2008 at 09:02:38AM -0700, Timothy Selivanow wrote:
So, under that logic, I should have named pysvn python-pysvn? That seems a bit redundant to me, but I'm willing to play along if that is the consensus. From now on, I'll make an effort to name things that way, unless I hear a better reason not to (name space pollution, lib-{package} naming in other distros, other historical reason that I'm not aware of or privy to...).
I agree that python-pysvn seems redundant, but that is the fault of the project creators, and is probably not up to packagers to correct. Naming a python package with "py" in the name is redundant itself. But, since you're going to have to "import pysvn", you might was well be installing python-pysvn.
Since I didn't make the deadline to have it included in F9, how difficult/frowned upon is it to change the package name. However, it is in F8 now...
--Tim _____________________________________________________________________________ < "See - the thing is - I'm an absolutist. I mean, kind of ... in a way ..." > ----------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).
python-devel@lists.fedoraproject.org
-
Kyle VanderBeek -
Timothy Selivanow -
Toshio Kuratomi