Zope 2 has a package named "Zope". Zope 3 has a package named "zope". Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both "Zope" and "zope" packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for: - The Zope software - Instance (site) specific packages So adding two directories, rather than one for the Zope software isn't a big deal. Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? 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
+1 It looks like in the Zope 2 trunk, there are only a very few places that rely on "import Zope" or "from Zope import". It looks like it would be possible to change the name of the "Zope" package in Zope 2 to "zope2" or something without a tremendous amount of work. And as long as a module alias was created to alias that to "Zope", 3rd party products would continue to work. This strategy would only work if we didn't plan on supporting systems where PYTHONCASEOK (see python -h) was set to be case-ignoring (are there any?). One potentially nasty problem is that the Zope 2 bootstrap code lives inside the Zope package within Zope.Setup, and some 3rd-party utilities (like the Plone Controller and many 3rd party tests that don't use the testrunner/test.py framework) rely on being able to "import Zope". Renaming the package pushes the responsibility for knowing about the name change out to those utilities (because there's really just nowhere to insert a module alias shim before they attempt to "import Zope"). Considering the pain that I know would be involved with doing a "zope" -> "zope3" rename, however, this might be an acceptable breakage (except of course to those whose code it breaks, so they should speak up). - C On Tue, 2004-04-13 at 10:40, Jim Fulton wrote:
Zope 2 has a package named "Zope". Zope 3 has a package named "zope". Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both "Zope" and "zope" packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for:
- The Zope software
- Instance (site) specific packages
So adding two directories, rather than one for the Zope software isn't a big deal.
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
Jim
Chris McDonough wrote:
+1
It looks like in the Zope 2 trunk, there are only a very few places that rely on "import Zope" or "from Zope import".
It looks like it would be possible to change the name of the "Zope" package in Zope 2 to "zope2" or something without a tremendous amount of work. And as long as a module alias was created to alias that to "Zope", 3rd party products would continue to work. This strategy would only work if we didn't plan on supporting systems where PYTHONCASEOK (see python -h) was set to be case-ignoring (are there any?).
One potentially nasty problem is that the Zope 2 bootstrap code lives inside the Zope package within Zope.Setup, and some 3rd-party utilities (like the Plone Controller and many 3rd party tests that don't use the testrunner/test.py framework) rely on being able to "import Zope". Renaming the package pushes the responsibility for knowing about the name change out to those utilities (because there's really just nowhere to insert a module alias shim before they attempt to "import Zope"). Considering the pain that I know would be involved with doing a "zope" -> "zope3" rename, however, this might be an acceptable breakage (except of course to those whose code it breaks, so they should speak up).
On Tue, 2004-04-13 at 10:40, Jim Fulton wrote:
<snip>
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
-1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
On Tuesday 13 April 2004 22:17, Tres Seaver wrote:
<snip>
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
-1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence.
You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? I would hate to have imports like "z3.app.foo" or even "z3.i18n". I am definitely -1 on this option, if it also applies to standalone Zope 3. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Tuesday 13 April 2004 22:17, Tres Seaver wrote:
<snip>
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
-1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence.
You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only?
Note that I am -0 to the idea.
I would hate to have imports like "z3.app.foo" or even "z3.i18n". I am definitely -1 on this option, if it also applies to standalone Zope 3.
I am just arguing that it would be saner to rename 'zope' to 'z3' (or 'zope3', or whatever) than to rename 'Zope' to 'zope2' (or whatever). Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Note that the reason I suggested renaming Zope to "zope2" (or whatever) as opposed to "zope" to "zope3" is because Zope 3 uses absolute imports almost everywhere; it would be far less work to change "Zope" to "Zope2" because Zope 2 either uses relative imports or assumes it can find what it needs on sys.path. I think the breakage, although literally "incalculable" (as is every change to Zope 2, given that it has no canonical API), would be manageable given enough lead time. In fact, if we did change the module name, we could just leave a "bruce" package in place that, when imported, raised a "ObsoleteError" with a descriptive message. I *hate* the idea of having two packages named "zope" where case is the only thing different. It's would be insanely difficult (not to mention embarrassing) to document, should the two codebases merge in some unholy fashion at some point as is on the 2.9 roadmap. - C ----- Original Message ----- From: "Tres Seaver" <tseaver@zope.com> To: <stephan.richter@tufts.edu> Cc: <zope3-dev@zope.org>; <zope-dev@zope.org> Sent: Tuesday, April 13, 2004 11:08 PM Subject: Re: [Zope3-dev] Re: Zope and zope
Stephan Richter wrote:
On Tuesday 13 April 2004 22:17, Tres Seaver wrote:
<snip>
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
-1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence.
You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only?
Note that I am -0 to the idea.
I would hate to have imports like "z3.app.foo" or even "z3.i18n". I am definitely -1 on this option, if it also applies to standalone Zope 3.
I am just arguing that it would be saner to rename 'zope' to 'z3' (or 'zope3', or whatever) than to rename 'Zope' to 'zope2' (or whatever).
Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org http://mail.zope.org/mailman/listinfo/zope3-dev
Chris McDonough wrote:
Note that the reason I suggested renaming Zope to "zope2" (or whatever) as opposed to "zope" to "zope3" is because Zope 3 uses absolute imports almost everywhere; it would be far less work to change "Zope" to "Zope2" because Zope 2 either uses relative imports or assumes it can find what it needs on sys.path.
Zope 3 is still (for a short time) in a far more plastic state. There aren't many third-party products and their authors expect change at this time. For example, we very recently rearranged the zope.app package.
I think the breakage, although literally "incalculable" (as is every change to Zope 2, given that it has no canonical API), would be manageable given enough lead time. In fact, if we did change the module name, we could just leave a "bruce" package in place that, when imported, raised a "ObsoleteError" with a descriptive message.
But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh.
I *hate* the idea of having two packages named "zope" where case is the only thing different.
Me too, the more I think about it.
It's would be insanely difficult (not to mention embarrassing) to document, should the two codebases merge in some unholy fashion at some point as is on the 2.9 roadmap.
Actually, the Zope 2.8 roadmap. :) Zope 2.8 will have Zope 3 interfaces. 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:
Chris McDonough wrote:
I think the breakage, although literally "incalculable" (as is
every change to Zope 2, given that it has no canonical API), would be manageable given enough lead time. In fact, if we did change the module name, we could just leave a "bruce" package in place that, when imported, raised a "ObsoleteError" with a descriptive message.
But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh.
Why is that a *big* problem? - It's not nice to break tests, but that doesn't necessarily mean the products are broken. - AFAICT many products need some polishing and a new release for Zope 2.8 anyway. Cheers, Yuppie
On 04/14/04 12:27, yuppie wrote:
Jim Fulton wrote:
But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh.
Why is that a *big* problem?
- It's not nice to break tests, but that doesn't necessarily mean the products are broken.
- AFAICT many products need some polishing and a new release for Zope 2.8 anyway.
I'm with Yuppie. With fundamental changes occurring in ExtensionClass and ZODB, lots of products are going to need a small revision anyway. For example, we've already started changing "from ZODB import Persistent" to "from Persistence import Persistent" everywhere. The majority of products that need to import Zope will just change from: from Zope import app to: try: from zope2 import app except ImportError: # Pre-Zope 2.8 from Zope import app I think it's cool that Python makes that so easy to do. Shane
Jim Fulton noted:
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
A bit ugly, but I can live with it. On Tuesday 13 April 2004 22:17, Tres Seaver wrote:
-1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence.
On Tuesday 13 April 2004 10:44 pm, Stephan Richter wrote:
You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only?
I would hate to have imports like "z3.app.foo" or even "z3.i18n". I am definitely -1 on this option, if it also applies to standalone Zope 3.
Tres has a good objection, *if* we actually expect 3rd-party Zope 2 code to work in Zope 3. (I don't know if we have this requirement or not; I've no personal interest in doing so.) If we don't expect 3rd-party Zope 2 code to work in Zope 3, then the second entry on sys.path seems good enough; having a collection of code identified by two different names is unworkable. (Think absolute imports here.) Any requirement that states 3rd-party Zope 2 code work in Zope 3 will have to be worked out; that's the key here. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Fred Drake wrote:
Jim Fulton noted:
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
A bit ugly, but I can live with it.
On Tuesday 13 April 2004 22:17, Tres Seaver wrote:
-1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence.
On Tuesday 13 April 2004 10:44 pm, Stephan Richter wrote:
You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only?
I would hate to have imports like "z3.app.foo" or even "z3.i18n". I am definitely -1 on this option, if it also applies to standalone Zope 3.
Tres has a good objection, *if* we actually expect 3rd-party Zope 2 code to work in Zope 3. (I don't know if we have this requirement or not; I've no personal interest in doing so.)
If we don't expect 3rd-party Zope 2 code to work in Zope 3, then the second entry on sys.path seems good enough; having a collection of code identified by two different names is unworkable. (Think absolute imports here.)
Any requirement that states 3rd-party Zope 2 code work in Zope 3 will have to be worked out; that's the key here.
-Fred
I have not done anything with z3 yet, tough we intend to start working with it soon. We have a number of products that are mostly plain python within a thin zope-shell. Since we probably would like to use them in z3 and must maintain them in z2 I would like to see a way to mix the two. Robert
Stephan Richter wrote:
On Tuesday 13 April 2004 22:17, Tres Seaver wrote:
<snip>
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
-1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence.
You wanna rename 'zope' to 'z3'
Tres doesn't. I want to solve the problem of having both "zope" and "Zope".
for the purpose of merging the two?
Yes
I really hope that will not be the case.
Why?
Or is this for Zope 2 only?
No, it would have to apply to both. Packages that would otherwise work with Zope 3 in Zope 2 should not have to be changed to be used with Zope 3.
I would hate to have imports like "z3.app.foo" or even "z3.i18n".
Why? What about "z.app.foo" or "z.i18n"? 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 Wednesday 14 April 2004 11:08, Jim Fulton wrote:
I want to solve the problem of having both "zope" and "Zope".
Great! I would very much prefer a solution like that.
> I really
hope that will not be the case.
Why?
I was referring to renaming "zope" to "zope3" or similar.
I would hate to have imports like "z3.app.foo" or even "z3.i18n".
Why?
Because in general I don't like version numbers in the path. I also think that "zope" is the only name that is 100% right on. Everything else is a compromise I would try to avoid. We will be sorry about it later, when many more people run Zope 3 only applications.
What about "z.app.foo" or "z.i18n"?
The shortness of this example is very attractive, but it is still a compromise in my opinion. Again, I think educating is easier than anything else. People understand that this is due to a merge of codebases and is for a transition period only. And, the TTW scripter will not care. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Wednesday 14 April 2004 11:08, Jim Fulton wrote:
...
What about "z.app.foo" or "z.i18n"?
The shortness of this example is very attractive, but it is still a compromise in my opinion.
Again, I think educating is easier than anything else. People understand that this is due to a merge of codebases and is for a transition period only. And, the TTW scripter will not care.
But this is a really important transition. It's a transition that will last at least a year or two, maybe longer, and will be an extremely sensitive period. I want things to go really well during this transition. 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 Wednesday 14 April 2004 11:36, Jim Fulton wrote:
Again, I think educating is easier than anything else. People understand that this is due to a merge of codebases and is for a transition period only. And, the TTW scripter will not care.
But this is a really important transition. It's a transition that will last at least a year or two, maybe longer, and will be an extremely sensitive period. I want things to go really well during this transition.
Me too! And I think some good transition documents can help explaining this. I will commit to writing them with the help of someone who knows Zope 2 well. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
On Wed, 2004-04-14 at 11:18, Stephan Richter wrote:
Because in general I don't like version numbers in the path. I also think that "zope" is the only name that is 100% right on. Everything else is a compromise I would try to avoid. We will be sorry about it later, when many more people run Zope 3 only applications.
I tend to agree, but if compromise is the only solution, then I'd tend to favor keeping Zope3 'clean'. We're planning on Zope3 being around much longer than Zope2, right? :) onions-are-tasty-but-not-in-the-varnish-ly y'rs, -Barry
On Wednesday 14 April 2004 11:44, Barry Warsaw wrote:
On Wed, 2004-04-14 at 11:18, Stephan Richter wrote:
Because in general I don't like version numbers in the path. I also think that "zope" is the only name that is 100% right on. Everything else is a compromise I would try to avoid. We will be sorry about it later, when many more people run Zope 3 only applications.
I tend to agree, but if compromise is the only solution, then I'd tend to favor keeping Zope3 'clean'. We're planning on Zope3 being around much longer than Zope2, right? :)
Yes, this is really what I meant. I want to keep Zope 3 clean too. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Jim Fulton wrote:
Zope 2 has a package named "Zope". Zope 3 has a package named "zope". Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both "Zope" and "zope" packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for:
- The Zope software
- Instance (site) specific packages
So adding two directories, rather than one for the Zope software isn't a big deal.
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
I should have been clearer. The first question is: Is it a problem to have two packages with names differing only in case? I haven't gotten as many responses on this as I expected. I'll try to summarize so far: - Chris feels strongly that this is a problem - I've been swayed by Chris' response from neutral to thinking that this is a problem. - Tres seems not to think this is a problem, but I'm not sure. - Fred doesn't seem to think this is a problem. - I can't tell from Robert's and Stephans responses whether they think this is a problem or not. Perhaps we can get more input on whether there's a problem. A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :) 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
+1 this is a problem. The question is whether curing it is *more* of a problem. -Casey On Wed, 14 Apr 2004 09:00:26 -0400 Jim Fulton <jim@zope.com> wrote:
Jim Fulton wrote:
Zope 2 has a package named "Zope". Zope 3 has a package named "zope". Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both "Zope" and "zope" packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for:
- The Zope software
- Instance (site) specific packages
So adding two directories, rather than one for the Zope software isn't a big deal.
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
I should have been clearer.
The first question is:
Is it a problem to have two packages with names differing only in case?
I haven't gotten as many responses on this as I expected. I'll try to summarize so far:
- Chris feels strongly that this is a problem
- I've been swayed by Chris' response from neutral to thinking that this is a problem.
- Tres seems not to think this is a problem, but I'm not sure.
- Fred doesn't seem to think this is a problem.
- I can't tell from Robert's and Stephans responses whether they think this is a problem or not.
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :)
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 Wed, 2004-04-14 at 09:00, Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
<snip>
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :)
+1 its probably a problem imo for mac users who are on a case insensitive fs. none of the alternative seem all that appealing though.. the comment about most z3 imports being prefixed with zope, suggests that any backwards porting with a goal of forward compatibility will require changing the existing z2 Zope package to something else, although sticking version numbers on package names doesn't hold much appeal for me. perhaps renaming z2 Zope->Core -kapil
Kapil Thangavelu wrote:
On Wed, 2004-04-14 at 09:00, Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
<snip>
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :)
+1
its probably a problem imo for mac users who are on a case insensitive fs.
none of the alternative seem all that appealing though..
Thanks for the input. I'd prefer to defer discussion on alternatives until we determine whether there is a problem we want to fix. 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 Wednesday 14 April 2004 09:54 am, Kapil Thangavelu wrote:
its probably a problem imo for mac users who are on a case insensitive fs.
Is this still an issue for Mac OS X, or is your concern for classic Mac OS? I don't know if we support that (simply because I've never heard anyone mention it).
none of the alternative seem all that appealing though.. the comment
No, they don't. The current Zope 3 naming for modules and packages mostly follows the current BDFL recommendations, which is nice, and is friendly to to those of use alergic to upper case letters. It also works well for case-senseless filesystems.
about most z3 imports being prefixed with zope, suggests that any backwards porting with a goal of forward compatibility will require changing the existing z2 Zope package to something else, although sticking version numbers on package names doesn't hold much appeal for me. perhaps renaming z2 Zope->Core
The Zope 2 "Zope" package is actually quite small. Perhaps renaming it is the best approach. In spite of Tres's objection, I don't see how there could be all that much code that references it. Perhaps it's referenced by some persistent objects? There's an uncertain comment in Zope.ClassFactory, and Zope.App.ClassFactory might be referenced, but otherwise the Zope package contains startup code. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
-1, it is not really a problem. As Chris pointed out, this will be hard to explain in documentation, but I think it will not be as big of a pain as requiring 3rd parties to change their code (this is for both, Zope 2 and 3). Furthermore, I really dislike the option of renaming "zope" in Zope 3 to something else. If you have a directory structure like lib/python Zope zope3/zope where both, 'lib/python' and 'lib/python/zope3' are in the path, then this is pretty obvious. I think that only advanced Zope 2.8+ programmers will want to use both Zope 2 and 3 functionality, so that educating them about this is much easier than educating the scripter. Regards, Stephan On Wednesday 14 April 2004 09:00, Jim Fulton wrote:
Jim Fulton wrote:
Zope 2 has a package named "Zope". Zope 3 has a package named "zope". Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both "Zope" and "zope" packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for:
- The Zope software
- Instance (site) specific packages
So adding two directories, rather than one for the Zope software isn't a big deal.
Of course, having two packages with names differing only in case is a bit ugly.
Do we want to consider renaming one or both of these packages to avoid the conflict?
I should have been clearer.
The first question is:
Is it a problem to have two packages with names differing only in case?
I haven't gotten as many responses on this as I expected. I'll try to summarize so far:
- Chris feels strongly that this is a problem
- I've been swayed by Chris' response from neutral to thinking that this is a problem.
- Tres seems not to think this is a problem, but I'm not sure.
- Fred doesn't seem to think this is a problem.
- I can't tell from Robert's and Stephans responses whether they think this is a problem or not.
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :)
Jim
-- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
I don't see a problem at all; IIRC, we agreed that the backports from Zope3 would live in a 'src' directory, while Zope 2 stuff continues to live in 'lib/python'. No case problem therefore, since they would be in different directories.
I haven't gotten as many responses on this as I expected. I'll try to summarize so far:
- Chris feels strongly that this is a problem
- I've been swayed by Chris' response from neutral to thinking that this is a problem.
- Tres seems not to think this is a problem, but I'm not sure.
- Fred doesn't seem to think this is a problem.
- I can't tell from Robert's and Stephans responses whether they think this is a problem or not.
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :)
-2 The reason why I don't see a big problem from the aesthetic point of view is that the 'Zope' package isn't used much in Zope2 anyway. Most stuff is in top-level packages such as OFS, App, Acquisition, ZPublisher, ZServer etc. I have Zope2 products that don't even import from 'Zope'. So, who would care? Renaming it would just be a hassle and asking for trouble (esp. regarding incompatabilies). I can see why it might be embarrassing having to document two package names that only differ by case. For newbies, it might even be confusing (though again, who ever gets in touch with lib/python/Zope?). But so is Zope2's codebase already. Most code is icky and naming conventions simply don't exist. Philipp
Philipp von Weitershausen wrote:
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
I don't see a problem at all; IIRC, we agreed that the backports from Zope3 would live in a 'src' directory, while Zope 2 stuff continues to live in 'lib/python'. No case problem therefore, since they would be in different directories.
As I mentioned in my note, Python allows us to have two packages whos names differ only by case. I also noted that this requires adding an additional directory to the path. This isn't a big deal. I think it's an annoyance.
I haven't gotten as many responses on this as I expected. I'll try to summarize so far:
- Chris feels strongly that this is a problem
- I've been swayed by Chris' response from neutral to thinking that this is a problem.
- Tres seems not to think this is a problem, but I'm not sure.
- Fred doesn't seem to think this is a problem.
- I can't tell from Robert's and Stephans responses whether they think this is a problem or not.
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :)
-2
Wow. That's a strong opinion that there's no problem :) especially since: ...
I can see why it might be embarrassing having to document two package names that only differ by case. For newbies, it might even be confusing
This sounds like an argument for there being a problem. I guess your large negative vote is a vote against the alternatives... fair enough. 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:
Jim Fulton wrote: ...
I should have been clearer.
The first question is:
Is it a problem to have two packages with names differing only in case?
I haven't gotten as many responses on this as I expected. I'll try to summarize
Wrong. People don't find the question useful. Give the responses. I need to recast my question as a selection among alternatives. But, before I do that, we will need to consider alternatives a bit more.
- Chris feels strongly that this is a problem
- I've been swayed by Chris' response from neutral to thinking that this is a problem.
In talking about this with Casey, Fred and Barry here, we thought of another problem with the status quo. The standard Python library has a module, pkgutil that facilitates spreading container packages like zope over multiple directories on the Python path. Thia facilitates installing zope-project packages in different places. Without this, container packages become very unsttractive. It turns out that pkgutil will be confused by the Zope package on Windows or Mac OS, adding it's directory to the zope package's path. This is a bug in pkgutil that can be fixed, but it is an example of the sorts of problems we can expect. In addition, haveing two packages with the same name makes it hard to talk about them verbally. One has to qualify the names, as in "big zope" or "little zope". 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: ...
Give the responses. I need to recast my question as a selection among alternatives. But, before I do that, we will need to consider alternatives a bit more.
OK, here's another. What about renaming the Zope 3 zope package to "z". - It fits with the expansion of "Zope": "Z Object Publishing Environment". - It's short :) - *At this time* (but after the move to svn), it's not too hard to make a change like this for Zope 3. Backward compatibility is not a big issue. This will change when X3.0 is released, which is why I'm bothering to deal with this now. - This was suggested a couple of years ago when coming up with the Zope 3 package layout. Examples (from the buddydemo example): import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent 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 Wed, Apr 14, 2004 at 11:06:37AM -0400, Jim Fulton wrote:
What about renaming the Zope 3 zope package to "z".
Examples (from the buddydemo example):
import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent
-1 for purely aesthetic reasons (IOW, I'm used to zope.something). Marius Gedminas P.S. I used to think ZOPE was a recursive acronym for the ZOPE Object Publishing Environment. <wink> -- Favorite MS-DOS error message: "Drive C: not ready, close door."
Marius Gedminas wrote:
On Wed, Apr 14, 2004 at 11:06:37AM -0400, Jim Fulton wrote:
What about renaming the Zope 3 zope package to "z".
Examples (from the buddydemo example):
import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent
-1 for purely aesthetic reasons (IOW, I'm used to zope.something).
Is this really just a matter of what you're used to? If you didn't have lots of experience typing "zope", would typing "z" instead really bother you? I actually like the z by itself. Perhaps because it echos the "circle z". I think I also like it because it seems to add less noise to the import lines. For example, I think I actually prefer: import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent to: import zope.interface from zope.app import zapi from zope.app.event import publish from zope.app.event.objectevent import ObjectModifiedEvent 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:
Jim Fulton wrote:
...
Give the responses. I need to recast my question as a selection among alternatives. But, before I do that, we will need to consider alternatives a bit more.
OK, here's another.
What about renaming the Zope 3 zope package to "z".
- It fits with the expansion of "Zope": "Z Object Publishing Environment".
- It's short :)
- *At this time* (but after the move to svn), it's not too hard to make a change like this for Zope 3. Backward compatibility is not a big issue. This will change when X3.0 is released, which is why I'm bothering to deal with this now.
- This was suggested a couple of years ago when coming up with the Zope 3 package layout.
Examples (from the buddydemo example):
import z.interface from z.app import zapi from z.app.event import publish from z.app.event.objectevent import ObjectModifiedEvent
Other reasons I like "z": - Less noise in imports - Echos the "circle z" - The packages in "z" can be used for more than just Zope - Emphasizes the more "minimalist" nature of Zope 3 relative to Zope 2 - "z" is a component of "zope" OK, I'm getting carried away. Sorry ;) 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 Wed, Apr 14, 2004 at 03:53:43PM -0400, Jim Fulton wrote: | Other reasons I like "z": | | - Less noise in imports | | - Echos the "circle z" | | - The packages in "z" can be used for more than just Zope | | - Emphasizes the more "minimalist" nature of Zope 3 relative | to Zope 2 | | - "z" is a component of "zope" | | OK, I'm getting carried away. Sorry ;) None of these sound like a strong argument. I dont buy it. +1 for renaming Zope to zope2. +0.9 for philiKON idea of putting zope into src/zope. -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Modeling paged and segmented memories is tricky business. -- P.J. Denning
Jim, let's make this telegraph style :)
OK, here's another.
What about renaming the Zope 3 zope package to "z".
+1
- It fits with the expansion of "Zope": "Z Object Publishing Environment".
- It's short :)
- *At this time* (but after the move to svn), it's not too hard to make a change like this for Zope 3. Backward compatibility is not a big issue. This will change when X3.0 is released, which is why I'm bothering to deal with this now.
+1
Other reasons I like "z":
- Less noise in imports
+1
- Echos the "circle z"
+0 (that's a marketing issue ;))
- The packages in "z" can be used for more than just Zope
+2
- Emphasizes the more "minimalist" nature of Zope 3 relative to Zope 2
+2 Philipp
On Thu, Apr 15, 2004 at 11:46:27AM +0200, Philipp von Weitershausen wrote: | >- The packages in "z" can be used for more than just Zope | | +2 So, here's an idea: - Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore. I've been using stuff from 'zope' (except 'zope.app') for a win32 app *wink*. So, what about this: zope.component zope.interfaces (?) zope.configuration zope.testing zope.schema (soon-to-be-dead?) - All move to 'ca.*' zope.app.* - Move down to 'zope'. This is pretty rough. Probably there are more stuff that should move to 'ca', and some stuff which should be grouped into packages, so that 'zope' doesn't get excessively broad. -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Breadth-first search is the bulldozer of science. -- Randy Goebel
Sidnei da Silva wrote:
On Thu, Apr 15, 2004 at 11:46:27AM +0200, Philipp von Weitershausen wrote: | >- The packages in "z" can be used for more than just Zope | | +2
So, here's an idea:
- Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore.
I've been using stuff from 'zope' (except 'zope.app') for a win32 app *wink*.
Great
So, what about this:
zope.component zope.interfaces (?) zope.configuration zope.testing zope.schema (soon-to-be-dead?)
- All move to 'ca.*'
Most of this has nothing to do with the component architecture. "ca" has nothing to do with zope.
zope.app.*
- Move down to 'zope'.
This doesn't solve name-conflict the problem. Or maybe I don't understand what you are proposing.
This is pretty rough. Probably there are more stuff that should move to 'ca', and some stuff which should be grouped into packages, so that 'zope' doesn't get excessively broad.
I think the depth vs breadth balence we have now is about right. 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 Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote: | >So, what about this: | > | >zope.component | >zope.interfaces (?) | >zope.configuration | >zope.testing | >zope.schema (soon-to-be-dead?) | > | >- All move to 'ca.*' | | Most of this has nothing to do with the component architecture. | | "ca" has nothing to do with zope. So that's the intention. If it has nothing to do with zope, why it should be prefixed with 'zope'? I may have been unlucky on trying to enumerate the packages. I was trying to figure out what kind of stuff would be useful in the context of zope2. Maybe you can enumerate what packages are part of the component architecture, and what packages would be used in zope2? I have a feeling that most stuff in zope.app would not be used in zope2, but I'm mostly surely wrong. | >zope.app.* | > | >- Move down to 'zope'. | | This doesn't solve name-conflict the problem. Or maybe I don't understand | what you | are proposing. See above. -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher The most important early product on the way to developing a good product is an imperfect version.
Sidnei da Silva wrote:
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote: | >So, what about this: | > | >zope.component | >zope.interfaces (?) | >zope.configuration | >zope.testing | >zope.schema (soon-to-be-dead?) | > | >- All move to 'ca.*' | | Most of this has nothing to do with the component architecture. | | "ca" has nothing to do with zope.
So that's the intention. If it has nothing to do with zope, why it should be prefixed with 'zope'?
From the zope package README.txt: "Zope Project Packages The zope package is a pure namespace package holding packages developed as part of the Zope 3 project. Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces. The one subpackage that's not usable outside the application server is the app subpackage, zope.app, which *is* the application server. Sub-packages of zope.app are not usable outside of the application server. If there's something in zope.app you want to use elsewhere, let us know and we can talk about abstracting some of it up out of zope.app."
I may have been unlucky on trying to enumerate the packages. I was trying to figure out what kind of stuff would be useful in the context of zope2.
Potentially, all of them.
Maybe you can enumerate what packages are part of the component architecture,
zope.component
and what packages would be used in zope2?
All of them, eventually probably including zope.app.
I have a feeling that most stuff in zope.app would not be used in zope2, but I'm mostly surely wrong.
I think you are probably wrong. But we don't know for sure yet.
| >zope.app.* | > | >- Move down to 'zope'. | | This doesn't solve name-conflict the problem. Or maybe I don't understand | what you | are proposing.
See above.
I still don't see how having a different package named "zope" addresses the name conflict with "Zope". 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 Thu, 2004-04-15 at 09:25, Jim Fulton wrote:
From the zope package README.txt:
"Zope Project Packages
The zope package is a pure namespace package holding packages developed as part of the Zope 3 project.
Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces.
Speaking as someone who's tried to use zope subpackages outside of z3, there are practical problems with this. About 8 months ago, I tried to pull ZPT, et al out to use as a standalone version. I ended up having to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and zope.i18n. All make sense (especially since I wanted internationalized ZPT), but tracking all the dependencies were difficult. I tried to update all that again a few weeks ago and found that I also now needed zope.i18nmessageid and zope.schema. It looks like Fred's packaging work will help with the very tricky task of figuring out the dependencies and creating distutils packages for the desired stuff. I've also heard that zope.schema is going away and that the dependency on both zope.i18n and zope.i18nmessageid might not be necessary. But I'm still concerned that there will be creeping dependencies among more things inside the zope package, making it harder to use some of those technologies independently. E.g. there are several standalone ZPT implementations in the wild, but I happen to think z3's is the best and would like to see it adopted more widely in the Python world. Also, for a long time I've wanted to see z3's interfaces package be used outside Zope3, perhaps even being adopted as a standard library package eventually. I wonder if living inside the zope container package helps or hurts those prospects. I understand the desire to carve out a package namespace that z3 can reliably use without risk of collision with other packages. I still think that's less of a practical concern in the Python world so I'd opt for an approach that gets the non-Zope specific technologies into the most hands of Python programmers. -Barry
Barry Warsaw wrote:
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote:
From the zope package README.txt:
"Zope Project Packages
The zope package is a pure namespace package holding packages developed as part of the Zope 3 project.
Generally, the immediate subpackages of the zope package should be useful and usable outside of the Zope application server. Subpackages of the zope package should have minimal interdependencies, although most depend on zope.interfaces.
Speaking as someone who's tried to use zope subpackages outside of z3, there are practical problems with this. About 8 months ago, I tried to pull ZPT, et al out to use as a standalone version. I ended up having to grab zope.interfaces, zope.pagetemplates, zope.tal, zope.tales, and zope.i18n. All make sense (especially since I wanted internationalized ZPT), but tracking all the dependencies were difficult. I tried to update all that again a few weeks ago and found that I also now needed zope.i18nmessageid and zope.schema.
It looks like Fred's packaging work will help with the very tricky task of figuring out the dependencies and creating distutils packages for the desired stuff.
Eactly. Freds work is going to adress this problem. (I'll restrain myself from going into a tirade about how important this is for Python. :)
I've also heard that zope.schema is going away
I thin it will eventually be merged into zope.interface.
and that the dependency on both zope.i18n and zope.i18nmessageid might not be necessary.
Right, maybe
But I'm still concerned that there will be creeping dependencies among more things inside the zope package, making it harder to use some of those technologies independently. E.g. there are several standalone ZPT implementations in the wild, but I happen to think z3's is the best and would like to see it adopted more widely in the Python world.
We're aware of this problem. That's why we've decoded to make the dependency data explicit (manually created) rather than implicit (automatically created). Each separately distributed package will have a DEPENDENCIES.cfg that is created by hand and that *constrains* dependencies on other packages. It makes explicit the intended dependencies. Dependencies not listed here are bugs. Adding depenencies to this file should be considered a big deal.
Also, for a long time I've wanted to see z3's interfaces package be used outside Zope3, perhaps even being adopted as a standard library package eventually. I wonder if living inside the zope container package helps or hurts those prospects.
Probably neither. I doubt that there will ever be a standard Python interface system. I'm not going to hold my breath. Guido argued for having Zope's interfaces be in s subpackage (or have a weird name) specifically to make it easier to add a standard interface package later, assuming that a standard package might not be exactly the same as Zope's.
I understand the desire to carve out a package namespace that z3 can reliably use without risk of collision with other packages. I still think that's less of a practical concern in the Python world
We've had colisions in the past. That's why we're being careful now. (BTW, I think it was a mistake to have top-level persistent and transaction packages. I think that will eventually come back to haunt us.) The only way to avoid collissions is to pick stupid names (zthis, zthat). I much prefer z.this to zthis. This assumes that we can make it easy to install z.this into z.
so I'd opt for an approach that gets the non-Zope specific technologies into the most hands of Python programmers.
I think that that's a different discussion. The safest thing to do for now is to continue using a container package. 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 Thu, 2004-04-15 at 10:23, Jim Fulton wrote:
Each separately distributed package will have a DEPENDENCIES.cfg that is created by hand and that *constrains* dependencies on other packages. It makes explicit the intended dependencies. Dependencies not listed here are bugs. Adding depenencies to this file should be considered a big deal.
That's very comforting! I like that it forces developers to be deliberate when adding cross-subpackage dependencies. -Barry
On Thursday 15 April 2004 10:23 am, Jim Fulton wrote:
(BTW, I think it was a mistake to have top-level persistent and transaction packages. I think that will eventually come back to haunt us.)
I won't disagree with this. ;-(
The only way to avoid collissions is to pick stupid names (zthis, zthat). I much prefer z.this to zthis. This assumes that we can make it easy to install z.this into z.
As long as z gets installed *at all* (before/after is not an issue), we can do this now. This is supported, if only by accident, by the current implementation of distutils.
I think that that's a different discussion. The safest thing to do for now is to continue using a container package.
I like this as well. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
From: "Sidnei da Silva" <sidnei@awkly.org>
- Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore.
'ca' feels weird. Canada? caca? I don't like it. 'z' is better then. Of course that means that suddenly the component architecture is called z, but that's OK, isn't it?
Lennart Regebro wrote:
From: "Sidnei da Silva" <sidnei@awkly.org>
- Move component-architecture packages out of 'zope' into 'ca', and then we don't have the 'zope' vs 'Zope' issue anymore.
'ca' feels weird. Canada? caca? I don't like it. 'z' is better then. Of course that means that suddenly the component architecture is called z
No, the component architecture is z.component. 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 Wednesday 14 April 2004 10:52 am, Jim Fulton wrote:
packages become very unsttractive. It turns out that pkgutil will be confused by the Zope package on Windows or Mac OS, adding it's directory to the zope package's path. This is a bug in pkgutil that can be fixed, but it is an example of the sorts of problems we can expect.
I've filed a bug report on pkgutil: http://www.python.org/sf/935117 -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
+1
A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :)
Jim
Andrew -- Zope Corporation Software Engineer (540) 361-1700
+0, not a problem. -1 for renaming 'Zope'. I endorse the 'src/zope' idea. Stefan On Mittwoch, Apr 14, 2004, at 15:00 Europe/Vienna, Jim Fulton wrote:
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates agreement that this is a probelm. :)
-- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
participants (18)
-
Andrew Sawyers -
Barry Warsaw -
Casey Duncan -
Chris McDonough -
Fred Drake -
Jim Fulton -
Kapil Thangavelu -
Lennart Regebro -
Marius Gedminas -
Michael Bernstein -
Philipp von Weitershausen -
robert rottermann -
Shane Hathaway -
Sidnei da Silva -
Stefan H. Holek -
Stephan Richter -
Tres Seaver -
yuppie