[Zope-dev] DomainAuthenticationMode with Sockets
Hi, I am trying to access by means of "sockets" to a folder that contains a acl_user folder with enabled DomainAuthenticationMode (domain_auth_mode=1) from a enabled IP in the domain (I have created a user specifying a domain with this IP and I have left the password for this user blank). It runs successfully HTTP via but it does not run Socket via requering authentication although I am in the domain. When I use HTTP via the Authenticated_User is Ok, however when I user Socket via the Authenticated_User is "Anonymous User". I am using "(Zope 2.7.5-final, python 2.3.5, linux2". Anybody help me about it? Does the DomainAuthenticationMode of a acl_user folder runs successfully via Socket ? Thanks ! ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-6-18 12:38 +0200: ... deprecation policy ... This policy allows us to move forward (which Zope 2 never really did for the the majority of those five years you mention). Although, it might help in a few cases, it is not at all necessary to cast ones history away when moving forward. I do not agree with you that Zope2 did not move forward in the past 5 years. I agree that currently it moves faster -- but not because you cast out things but because you move lots of new functionality in. +lots Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
Philipp von Weitershausen wrote: It's dead from a maintenance point of view. If you still want to maintain it, be our guest. But you yourself said that maintaining too many branches is madness. My point is that we're creating too many branches ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
--On 26. Juni 2006 11:25:05 +0100 Chris Withers [EMAIL PROTECTED] wrote: Philipp von Weitershausen wrote: It's dead from a maintenance point of view. If you still want to maintain it, be our guest. But you yourself said that maintaining too many branches is madness. My point is that we're creating too many branches ;-) Bascially 3 at this time. As I pointed out earlier it does not take too much effort e.g. to apply fixes to the 2.8 branch *as needed*. Andreas pgpvjvZ0Kq91H.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
A small question/idea. When making svn:externals in Nuxeo, we always use https. That way trees can still be checked out anonymously, but still modified. in Zope, threes are checked out with svn+ssh, but externals use svn. That means that when you want to modify for example Five, you need to delete the svn checkout and do an svn+ssh checkout instead. Also, if you start changing things without remembering that you have to make a fresh checkout, you have to svn diff it and them manually merge it into the fresh checkout, and if you later do an svn up, your changes will be moved into a dead *.OLD directory (where you can't do svn diff to extract your changes) and so on. The benefit of that is that you don't by mistake check in on a tag... My question is: Is there a good way of not having to check out a fresh copy before you do changes? If not how would people feel about switching to https or something instead? Especially if we merge the trees, in which case both Zope2 and Zope3 will be made up mainly of svn:externals... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Flood of deprecation warnings...
On 6/26/06, Chris Withers [EMAIL PROTECTED] wrote: Oh please, stop the FUD. Not FUD, whatever you mean by that here... Right. FUD is when you intentionally spread unjustified Fear, Uncertainty and Doubt about things to hurt them. You don't. You may HAVE the above things, but if it is justified or not, it's definitely not FUD. :) (I'd say it's justified. Things are happening and happening quickly. It's completely justified to get spooked about that when you rely on stability). Well, 2.10 is about to be cut, no? That technically makes 2.9 no longer supported, right? (in the same way that 2.8 is not currently the active maintenance branch...) No, 2.8 is in active maintenance. 2.8 will go out of active maintenance when 2.10 is cut. (I think the linux model of 2.odd being dev and 2.even being stable (I may well have those the wrong way round) is designed to prevent excessive branching... Maybe. It's designed to give you the ability to have resonable release numbers even for unstable branches, instead of calling it alpha 1, 2, 3, 4 and beta 1, 2, 3, 4. For me it doesn't make a difference. In fact, I prefer that it is expleicitly called alpha or beta. The stable/unstable numbering scheme is useful if you have a ver long time, like years, betweeen stable releases. We didn't want that. Maybe that was wrong, but I don't think so. It's probably just as much a matter of taste as a matter of what you want out of Zope development. I don't think there's enough clarity between when something is time based and when something is number based... And, in all honesty, a year is too short a period of time... 2 years is more realistic for most projects I've worked on. Yes, but two years of what? Don't you think you will have found most bugs after the first year? And if you find more bugs, even after one year these can still be fixed. If they are easy to fix, you can do it. If they are fixed in later versions, somebody can most likely be easily convinced to backport them for a reasonable monetary contribution. If they are weird and obscure bugs that doesn't exist in later versions, or require huge changes in large parts of Zope, well, then you are going to have to switch versions *anyway*. I need to repeat this: Zope 2.7 did not disappear or stop working when Zope 2.9 was released. All that happened was that the people involved in active development of Zope said right, we are no longer automatically backporting fixes to 2.7. That's is. That's all that happened. My personal sites run on Python 2.1.something and Zope 2.5. They did not explode or stop working When Zope 2.7 came out. 2.5 was released January 25th 2002. Is four years long enough? :) (I'm just nagging you now, don't take it seriously). If Zope would have been a closed source Microsoft software, I would have TOTALLY agreed with you. Because any problem that then pops up is dependant on the support of the company. When MS drops support for a version of software, that's pretty much the death of using that version in a serious project. But Zope is open source. Any problem that is there can be fixed, even if it is not longer actively maintained. Sometimes we learn from the past and our views on things change (still think implicit acquisition is a good idea? ;-) ). I'm certainly not trying to put any burden on Andreas, I'm questioning the policies which seem ot have resulted in so many branches that need maintaining... Well, the only way to cut down on those branches is either to cut down on support of older versions (and you sure don't want that) or cut down the amount of new releases (and I sure don't want that). This means that we have a conflict of maintainability and development, and we need to find the right compromise. I'm not convinced that the current comprmise is not right. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Database mounting problem in 2.9.3?
Dieter Maurer wrote: Chris Withers wrote at 2006-6-23 17:12 +0100: Get this error on startup with one project I've just moved to Zope 2.9.3: File /usr/local/zope/2.9.3/lib/python/Zope2/Startup/datatypes.py, line 175, in createDB return ZODBDatabase.open(self, databases) File /usr/local/zope/2.9.3/lib/python/ZODB/config.py, line 105, in open databases=databases) File /usr/local/zope/2.9.3/lib/python/ZODB/DB.py, line 262, in __init__ raise ValueError(database_name %r already in databases % ValueError: database_name 'packed' already in databases You see here the new (ZODB 3.6) multi-database support. Something tries to ad the database packed to a multi-database that already contains a packed. This might happen when you mount the same storage at different places into your hierarchy. Indeed, and this is a perfectly legitimate use case... I have a Packed.fs and an UnPacked.fs: /content from Packed.fs is mounted to /content of UnPacked.fs /Catalog from Packed.fs is mounted to /Catalog of UnPacked.fs ...for this project, content is managed elsewhere and often imported into Zope, so packing very often is a necessity. Unpacked.fs contains code, user information, etc, which should never be packed. So, two questions: 1. Is this a ZODB or a Zope bug? (ie: which collector do I file this in?) 2. Given that this is an exception being raised rather than a log message, how come everything works fine even after the exception has been reported? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unify the Zope 2 and Zope 3 repositories!
Chris Withers wrote: Philipp von Weitershausen wrote: Jim suggested a different strategy with Zope 5 (http://mail.zope.org/pipermail/zope3-dev/2006-February/018415.html). The little bits and pieces that make up Zope 3 (the zope.* packages) would be developed more or less independently of Zope-the-app-server (which would only be one product called Zope 5 and incorporate ideas from Zope 2 and 3 and use those bits and pieces). Well, the sooner better... ...this comes mainly from my desire to see the exponential combination of branches problem go away... Technically speaking, isn't that a squared problem? -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science Phone: +45 66 11 84 94 Mobile: +45 29 93 42 96 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: Zope/branches/2.9/lib/python/ Replace bulk of uses of 'zLOG' with equivalent Python 'logging' module usage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: --On 25. Juni 2006 16:32:04 +0200 Stefan H. Holek [EMAIL PROTECTED] wrote: This, BTW, breaks CMF 1.5 on Zope 2.9. Not sure I/you should care though ;-) Traceback (most recent call last): File /home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFActionIcons/__init__.py, line 19, in ? from Products.CMFCore.DirectoryView import registerDirectory File /home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFCore/__init__.py, line 21, in ? import MembershipTool, WorkflowTool, CatalogTool, DiscussionTool File /home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFCore/CatalogTool.py, line 23, in ? from Products.ZCatalog.ZCatalog import LOG ImportError: cannot import name LOG Tres, you replace all 'LOG' vars with 'logger'. Is there a reason for this replacement? We've been using LOG through out the complete Z2 core..we should remain consistent in some way. Hmm, the API of the logger objects is not consisistent with the old log objects. I don't know why CMF is importing that name from the catalog, but I guess we need to leave it there for BBB. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoAR1+gerLs4ltQ4RApUIAKCBNda8NW538LZzWWijpQgJOT0FOACgiA9y jxcAyITHNUylCcf74k7kPSE= =stG6 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: A small question/idea. When making svn:externals in Nuxeo, we always use https. That way trees can still be checked out anonymously, but still modified. in Zope, threes are checked out with svn+ssh, but externals use svn. That means that when you want to modify for example Five, you need to delete the svn checkout and do an svn+ssh checkout instead. Also, if you start changing things without remembering that you have to make a fresh checkout, you have to svn diff it and them manually merge it into the fresh checkout, and if you later do an svn up, your changes will be moved into a dead *.OLD directory (where you can't do svn diff to extract your changes) and so on. The benefit of that is that you don't by mistake check in on a tag... My question is: Is there a good way of not having to check out a fresh copy before you do changes? If not how would people feel about switching to https or something instead? Especially if we merge the trees, in which case both Zope2 and Zope3 will be made up mainly of svn:externals... - -1. The externals are just that, external to the Zope project. Modifying them should require extra thought, and a little extra effort, because the possibility exists that the change might break something outside the Zope tree. When we get to an egg-based Zope install, I think such a gesture would map onto check out the source egg and force it into the path.' Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoB5L+gerLs4ltQ4RAqfRAKDUrcW7NYg4ljtHvYZto3H5hARV1gCglHWv 2pqpEsGwE1h6rckFpJgcmTo= =/cbq -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Flood of deprecation warnings...
Chris Withers wrote: Philipp von Weitershausen wrote: Chris Withers wrote: Florent Guillaume wrote: Chris Withers wrote: Both core zope and Plone spew forth in their default state. Zope 2.10 does? It shouldn't. Please point out the deprecation warnings it sends. I, like many people I suspect, am still struggling to get projects onto 2.8/2.9. The thought that they're both going to be obsolete already fills me with dread :-( Oh please, stop the FUD. Not FUD, whatever you mean by that here... I'm referring to your handwaving based on false information. Dread as you call it above is typically defined as the anticipation of apprehension of fear (Oxford American Dictionary). Spreading fear based upon false information is pretty close to FUD, I'd say. Zope 2.9 is well within its normal release cycle and not going out of style for a long time. Well, 2.10 is about to be cut, no? That technically makes 2.9 no longer supported, right? Nope. Zope 2.9 is in bugfix mode, at least for another 6 months and beyond that as long as people want to support it. (in the same way that 2.8 is not currently the active maintenance branch...) Still wrong. Zope 2.8 is still maintained. Andreas hasn't said anything yet about not making any more Zope 2.8 releases. If what we're really saying is that we've agreed to keep the previous two release branches maintained, then I assert we're branching too often ;-) (I think the linux model of 2.odd being dev and 2.even being stable (I may well have those the wrong way round) is designed to prevent excessive branching... As Martijn pointed out already, this model makes it difficult to get features released at a definite point in time. Zope 2.7 and 2.8 were releases bloated with features that seemed to have taken forever. Zope 2.7 took more than two years. Zope 2.8 took more than one year and could be right up with Zope 2.7 if it hadn't been for Five. Andreas had the idea of phasing out Zope 2 releases one year after their first release, which would mean that Zope 2.8 would be phased out soon, but not yet. I don't think there's enough clarity between when something is time based and when something is number based... I think there's lots of clarity. We make a major release every six months. That's the 'y' in x.y.z. Then the release managers may decide to make minor releases based on the number and necessities of bugfixes during the maintenance period. This is the 'z' in x.y.z. And, in all honesty, a year is too short a period of time... 2 years is more realistic for most projects I've worked on. Fine. Nobody said that we can't change this policy. BUT, just because you have Zope 2.7 in production doesn't mean we still need to actively maintain Zope 2.7. Of course, everyone's free to still do so if s/he needs bugfixes in there, but so far that hasn't happened. You're really the only one complaining so far, and actually haven't given any examples yet of where you see a problem with Zope 2.7 not being maintained anymore. Or Zope 2.8, for that matter (even though it still is). Plus, if you care to make more Zope 2.8 releases, by all means, do it. But don't burden Andreas with even more work when YOU once agreed to his very policy (see http://mail.zope.org/pipermail/zope-dev/2005-October/025556.html). Sometimes we learn from the past and our views on things change (still think implicit acquisition is a good idea? ;-) ). I'm certainly not trying to put any burden on Andreas, I'm questioning the policies which seem ot have resulted in so many branches that need maintaining... Sure, we all change our views. I think the number of branches isn't a problem, though. They seem to retire themselves pretty quickly (about a year after the initial stable release). Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
On 6/26/06, Tres Seaver [EMAIL PROTECTED] wrote: - -1. The externals are just that, external to the Zope project. Uhm. I have a hard time seeing Five and lib/python/zope as external to Zope. When we get to an egg-based Zope install, I think such a gesture would map onto check out the source egg and force it into the path.' Yeah, with eggs this issue might go away... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: On 6/26/06, Tres Seaver [EMAIL PROTECTED] wrote: - -1. The externals are just that, external to the Zope project. Uhm. I have a hard time seeing Five and lib/python/zope as external to Zope. They are managed as separate projects, with their own priorities and releases. ZODB is the longest-running example of this externality. When we get to an egg-based Zope install, I think such a gesture would map onto check out the source egg and force it into the path.' Yeah, with eggs this issue might go away... Right. The 'svn:externals' will morph into dependencies, which will still be managed exterally to the dependent package. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoCer+gerLs4ltQ4RAqnwAKCVr5TeOU0XyLG/6drpaTJ65lGgiwCfbD74 V6ArZP8baL0Vo2fafxJQYOg= =fcxE -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DomainAuthenticationMode with Sockets
Juan Javier Carrera Obrero wrote at 2006-6-26 09:52 +0200: ... Does the DomainAuthenticationMode of a acl_user folder runs successfully via Socket ? What should via Socket mean? All standard HTTP requests work via socket. DomainAuthentication seems to work because there have been occasional questions in the mailing list and usually no followups after the domain_auth_mode has been activated. Cannot tell you why it does not work for you... -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Database mounting problem in 2.9.3?
Chris Withers wrote at 2006-6-26 14:16 +0100: ... You see here the new (ZODB 3.6) multi-database support. Something tries to ad the database packed to a multi-database that already contains a packed. This might happen when you mount the same storage at different places into your hierarchy. Indeed, and this is a perfectly legitimate use case... I have a Packed.fs and an UnPacked.fs: /content from Packed.fs is mounted to /content of UnPacked.fs /Catalog from Packed.fs is mounted to /Catalog of UnPacked.fs ... So, two questions: 1. Is this a ZODB or a Zope bug? (ie: which collector do I file this in?) I do not know, yet. We are still using ZODB 3.4 and multi-database support was added in ZODB 3.6. But, I expect it is a Zope bug because both of your mounts could (and almost surely should) use the same database and connection. Both Zope and ZODB use the same collector. ZODB bugs get the category database. I would file the bug report in this way (Zope collector with category database) even if it is not a ZODB error (at least it is database related). 2. Given that this is an exception being raised rather than a log message, how come everything works fine even after the exception has been reported? I do not know -- as I did not yet analyse such a problem. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Tres Seaver wrote:
The point is that the release tarball should generate the same
environment that the developers routinely work in; otherwise, we leave
the poor suckers who install from it stuck with whatever bugs are caused
by the difference.
Ok. I'll note that Python eggs don't fulfill that goal of having a
development area look like a package or an installed version either.
When we get there, I think the developer will install a single meta-egg,
which then pulls down and installs the others. At that point, she will
be working in the same environment as everyone else. When she wants to
modify a package, she will check it out separately and run the 'develop'
command, which will force the checkout onto her path as a source egg.
Maybe we'll even have a script available which makes this a simpler process.
I'll agree that these items ought not to be in the Zope2 tree: fixing
that *in the checkout* would be a worthwhile effort.
Indeed; in fact, we always wished they hadn't been there in the first
place. Of course, in the end we hope that zope.app won' thave to be in
Zope 2 at all anymore.
That will be good. Even after eliminating the list you provided (see
below), there is still a lot of stuff in zope.app which is irrelevant to
Zope2 (I think).
The simplest approach I can see to that would be:
- On the Zope3 side, make it a rule that 'zope.app' contains only
packages, not modules, converting the existing modules into
packages with '__init__.py' corresponding to the current modules.
Move the corresponding tests down into the new packages, as well.
Currently, that would involve changing the following:
o zope.app.datetimeutils
o zope.app.decorator
o zope.app.servicenames
o zope.app.timezones
Alternatively, if any of those modules is not used in Zope2
(it appears that 'datetimeutls' is the only one so used, except
that it uses 'timezones'), we could leave them alone.
- Make the 'app' directory on the zope2 side a non-external,
containing its own externals pointing to the packages we want
to ship with Zope2.
Sounds like the simplest approach indeed. I'm +1. I'm -1 on moving
anything around other than turning modules into packages, though. Moving
things around bares risks of breaking something. We can't afford that
within a stable release series. Not moving the tests won't be a problem
because zope.app tests aren't run in Zope 2 anyways. If they were run
we'd get lots of failures anyways, because zope.app stuff is quite
interwoven.
I've created a new branch from the 3.2 branch which makes the changes I
proposed: i.e. 'datetimeutils', 'timezones', and 'decorators' become
packages, and their tests move from 'zope/app/tests/' to their own
'tests' subdirectory (none of those tests exported facilities used by
any other tests.
All unit and functional tests pass on that branch, with identical
results to the 3.2 tree.
I have also morphed the 'zope.app' package in my 'tseaver-retire_zpkg'
branch to point into this new branch, eliminating the dead packages
you described. The only forked code is the empty __init__.py, which
seems an acceptable tradeoff. I added an EXTERNALS.txt file which
documents the intended links.
BTW, a small nit of mine with subversion: can anybody tell me how to
find the revision in which a directory was moved / removed, preferably
via the web interface? Subversion doesn't seem to expose a way to ask
about a name which, like the man upon the stair isn't there any more.
Also note that all of the above have been deprecated in Zope 3.3/2.10
(datetimeutils, decorator and timezones have been moved to the zope.*
level, servicenames has been made obsolete).
Yup, the same general approach should work in the 2.10 tree.
I've now done the same work on a branch for that tree:
[/home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10]
$ head .svn/entries
?xml version=1.0 encoding=utf-8?
wc-entries
xmlns=svn:
entry
committed-rev=68857
name=
committed-date=2006-06-26T21:16:14.182239Z
url=svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-retire_zpkg-2.10
last-author=tseaver
kind=dir
Note that here I used the contents of 'zope.app' as installed by the
2.10b1 tarball, which has at least one of the packages in it ('wfmc')
which Philipp said should be excluded for 2.9.
AFAIK, both of these branches are ready for merging to their respective
branches (and to the trunk, for the 2.10 version).
Comments?
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla -
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
Tres Seaver wrote:
I've now done the same work on a branch for that tree:
[/home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10]
$ head .svn/entries
?xml version=1.0 encoding=utf-8?
wc-entries
xmlns=svn:
entry
committed-rev=68857
name=
committed-date=2006-06-26T21:16:14.182239Z
url=svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-retire_zpkg-2.10
last-author=tseaver
kind=dir
Btw, I found 'svn info' the other day. Before that I was looking at
.svn/entries, too.
Note that here I used the contents of 'zope.app' as installed by the
2.10b1 tarball, which has at least one of the packages in it ('wfmc')
which Philipp said should be excluded for 2.9.
AFAIK, both of these branches are ready for merging to their respective
branches (and to the trunk, for the 2.10 version).
Comments?
Looks good. Let's merge :)
Philipp
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
