We need to make a decision wrt distribution names
Obviously, we are having a debate about what forms distribution names can take. I think we need a decision. Does anyone know if there are existing rules for package names? I can't find them if there are. Up until now, I think we've been in somewhat of a prototyping mode, but I think it's time to move beyond that. I strongly suggest that we need an official specification that says: - what's a legal package name and - what the equivalence rules for package names are. Whatever we decide needs to be well supported by setuptools and PyPI. I can live with whatever we decide as long as we decide something and make sure it is well communicated and implemented. In particular, I could live with the equivalence rules that setuptools uses if they are documented and if they are supported correctly and efficiently by the index (including mirrors). IMO, a decision is extremely important. If we can't reach consensus, then we need to call in the BDFL. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Does anyone know if there are existing rules for package names? I can't find them if there are. ...
Well, there is PEP 8, which has this to say on the subject: "Package and Module Names "Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged." Steve
On Jul 24, 2007, at 12:36 PM, Jim Fulton wrote:
Obviously, we are having a debate about what forms distribution names can take. I think we need a decision.
Does anyone know if there are existing rules for package names?
Doh. I meant "distribution names". Sorry.
I can't find them if there are. Up until now, I think we've been in somewhat of a prototyping mode, but I think it's time to move beyond that.
I strongly suggest that we need an official specification that says:
- what's a legal package name and
Ditto
- what the equivalence rules for package names are.
Ditto.
Whatever we decide needs to be well supported by setuptools and PyPI. I can live with whatever we decide as long as we decide something and make sure it is well communicated and implemented. In particular, I could live with the equivalence rules that setuptools uses if they are documented and if they are supported correctly and efficiently by the index (including mirrors).
IMO, a decision is extremely important. If we can't reach consensus, then we need to call in the BDFL.
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Jul 24, 2007, at 12:49 PM, Stephen Waterbury wrote:
Jim Fulton wrote:
Does anyone know if there are existing rules for package names? I can't find them if there are. ...
Well, there is PEP 8, which has this to say on the subject:
"Package and Module Names
"Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged."
Doh, I was sloppy in my terminology. I should have said "distribution name". We're talking about the names used in PyPI, the Python Distribution index. ;) Also the value passed to the "name" argument of setup. Sorry for the confusion. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
On Jul 24, 2007, at 12:49 PM, Stephen Waterbury wrote:
Jim Fulton wrote:
Does anyone know if there are existing rules for package names? I can't find them if there are. ...
Well, there is PEP 8, which has this to say on the subject:
"Package and Module Names
"Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged."
Doh, I was sloppy in my terminology. I should have said "distribution name". We're talking about the names used in PyPI, the Python Distribution index. ;) Also the value passed to the "name" argument of setup.
Sorry for the confusion. :)
Actually, I wasn't confused. :) I'd suggest a convention that allows a distribution "title" (e.g., "Zope", "Twisted", etc.) and a distribution "name" that would simply be the name of the distribution's top-level package (e.g., "zope", "twisted", etc.), which should follow the PEP 8 suggestion for package names and should be what setuptools uses together with a version reference to uniquely identify a specific distribution/version (egg). Steve
I strongly suggest that we need an official specification that says:
The process would then be to write a PEP. It will end with a BDFL pronouncement either way, but that might be easy to obtain if there is consensus up-front. Regards, Martin
At 01:09 PM 7/24/2007 -0400, Stephen Waterbury wrote:
Actually, I wasn't confused. :) I'd suggest a convention that allows a distribution "title" (e.g., "Zope", "Twisted", etc.) and a distribution "name" that would simply be the name of the distribution's top-level package (e.g., "zope", "twisted", etc.),
This proposal would rule out namespace packages, in addition to being incompatible with existing distribution names. Note that package != distribution -- a distribution may contain zero or more packages (even top-level), *and* a single package (top-level or otherwise) may be spread over more than one distribution. Also note that this was true even with the distutils, long before setuptools existed.
Phillip J. Eby wrote:
At 01:09 PM 7/24/2007 -0400, Stephen Waterbury wrote:
Actually, I wasn't confused. :) I'd suggest a convention that allows a distribution "title" (e.g., "Zope", "Twisted", etc.) and a distribution "name" that would simply be the name of the distribution's top-level package (e.g., "zope", "twisted", etc.),
This proposal would rule out namespace packages ...
I thought about that. The rule for namespace distributions would be to allow dotted names, e.g. "zope.interface", "zope.schema", etc., as are often currently used. In fact, in a real sense, those *are* the top-level packages of namespace packages.
in addition to being incompatible with existing distribution names.
I thought the point was to come up with a new distribution naming convention, because there currently isn't one -- but the naming convention has to be consistent with all existing distribution names? Seems a tough constraint.
Note that package != distribution ...
Yes, I knew that. Of course, now the discussion seems to suggest "project" or "project release" might be a better name than "distribution", and I agree with that.
-- a distribution may contain zero or more packages (even top-level) ...
Indeed, and I've always disliked multiple top-level packages in an [installable unit]. I never liked ZODB strewing top-level packages all over site-packages. (But I do like ZODB -- thanks Jim et al.! I'd just much prefer that it have a top-level "zodb" package.) Of course, eggs make site-packages dirs look much tidier, but I'd still prefer that each [installable unit] have a top-level package, because then it's obvious where imported modules come from just by looking at their top-level namespace.
*and* a single package (top-level or otherwise) may be spread over more than one distribution.
IMO, a package that's spread over more than one distribution should probably not be top-level in both distributions. :) BTW, I am not emotionally attached to this proposal (good thing, eh? ;), but there are a couple of principles in it that I thought deserved a little bit of logical advocacy, e.g.: * if a package deserves a "top-level" namespace, it probably also deserves have its own [installable unit]. * although package != [installable unit], I still think it's not illogical to use the top-level package of an [installable unit] as part of its canonical unique identifier. But admittedly one would have to agree with some of my other points above to agree with that. Steve
At 09:56 PM 7/24/2007 -0400, Stephen Waterbury wrote:
I thought the point was to come up with a new distribution naming convention,
Nope, just clarify the rules for *distinguishing* projects by name -- a much less ambitious goal, since it's pretty easy to do with little or no impact on existing projects. A new naming convention isn't in scope, since it would require a "boil the ocean" renaming effort to implement, assuming you could get everyone to agree in the first place.
Phillip J. Eby wrote:
At 09:56 PM 7/24/2007 -0400, Stephen Waterbury wrote:
I thought the point was to come up with a new distribution naming convention,
Nope, just clarify the rules for *distinguishing* projects by name -- a much less ambitious goal, since it's pretty easy to do with little or no impact on existing projects.
A new naming convention isn't in scope, since it would require a "boil the ocean" renaming effort to implement, assuming you could get everyone to agree in the first place.
Indeed. Boiling the ocean will have to wait. I still think putting multiple top-level packages in a single installable is a mistake. ;) Peace. Steve
On Jul 24, 2007, at 10:19 PM, Phillip J. Eby wrote:
At 09:56 PM 7/24/2007 -0400, Stephen Waterbury wrote:
I thought the point was to come up with a new distribution naming convention,
Nope, just clarify the rules for *distinguishing* projects by name -- a much less ambitious goal, since it's pretty easy to do with little or no impact on existing projects.
I mostly agree, except that I think we also need to define what is legal in a project name. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Jul 24, 2007, at 9:56 PM, Stephen Waterbury wrote:
Phillip J. Eby wrote:
At 01:09 PM 7/24/2007 -0400, Stephen Waterbury wrote:
Actually, I wasn't confused. :) I'd suggest a convention that allows a distribution "title" (e.g., "Zope", "Twisted", etc.) and a distribution "name" that would simply be the name of the distribution's top-level package (e.g., "zope", "twisted", etc.),
This proposal would rule out namespace packages ...
I thought about that. The rule for namespace distributions would be to allow dotted names, e.g. "zope.interface", "zope.schema", etc., as are often currently used. In fact, in a real sense, those *are* the top-level packages of namespace packages.
Those are the top-level packages of those distributions.
in addition to being incompatible with existing distribution names.
I thought the point was to come up with a new distribution naming convention, because there currently isn't one -- but the naming convention has to be consistent with all existing distribution names? Seems a tough constraint.
No, my proposal was to define: - Rules for constructing *legal* (as opposed to "good") project names - Rules for variations on project names. ...
-- a distribution may contain zero or more packages (even top-level) ...
Indeed, and I've always disliked multiple top-level packages in an [installable unit].
No offense intended, but this seems arbitrary to me. Note that not only can a distribution contain more than one package, it can contain no packages.
*and* a single package (top-level or otherwise) may be spread over more than one distribution.
IMO, a package that's spread over more than one distribution should probably not be top-level in both distributions. :)
Phillip was (I think) referring to namespace packages. Namespace packages are a very important tool for maintaining some sanity in package naming. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (4)
-
"Martin v. Löwis" -
Jim Fulton -
Phillip J. Eby -
Stephen Waterbury