[Zope3-dev] Zope3 tarball build/test run log
Traceback (most recent call last):
File /home/jinty/releases/release-assistent.py, line 260, in ?
main(sys.argv)
File /home/jinty/releases/release-assistent.py, line 257, in main
builder.run()
File /home/jinty/releases/release-assistent.py, line 169, in run
self.buildReleases()
File /home/jinty/releases/release-assistent.py, line 177, in buildReleases
self.buildRelease()
File /home/jinty/releases/release-assistent.py, line 226, in buildRelease
self.runner.runMany(self.release['test_command'])
File /home/jinty/releases/release-assistent.py, line 157, in runMany
self.run(cmd)
File /home/jinty/releases/release-assistent.py, line 152, in run
raise CommandException('%s failed!' % cmd)
__main__.CommandException: cd tst bin/zopetest failed!
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Putting pullparser and clientform where they belong (reverting 39890)
On Tue, Jan 03, 2006 at 07:13:16AM -0500, Jim Fulton wrote: Brian Sutherland wrote: Since we are close to the release, I felt compelled to ask before I did this. Could I revert 39890 [1] for the 3.2 release? No. Ok, good thing I asked first then;) I'll work around it or wait. Why wait until we are close to the release? Because I only realized it was causing a headache for me yesterday. It seems that phillip finished zpkg's module support some time ago [2]. (I ask as this is causing me headaches doing the Debian packaging for the latest zope3) The first beta was nearly 2 months ago. We are trying to do timed releases and we've already missed the deadline. I'm not willing to delay 3.2 final for this. I am willing to consider a 3.2.1 release for this *after* the final. That would also be fine. Why do you think you need to do this? It is related to the debian packaging of zope 3. It is common practice with these packages to remove modules that can be provided by other debian packages. So far this has been the case only with pytz and docutils. The relevant code in the debian rules file is (yes, I know it is nasty, but there doesn't seem to be a right way): zbase= Zope-3.2.0b2 snip unpack: unpack-stamp unpack-stamp: tar xfz $(zbase).tgz mv $(zbase) z # Remove docutils and pytz modules packaged in separate packages rm -rf z/Dependencies/docutils* rm -rf z/Dependencies/pytz* I also need to do the same with mechanize and it's dependencies. Since the latest version of mechanize depends on pullparser 0.0.7, I also need to remove pullparser. This is more difficult with the way pullparser is tied into zope today. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [Patch] i18nextract implement exclude paths
On Tuesday 03 January 2006 05:52, Encolpe Degoute wrote: Simon Michael [EMAIL PROTECTED] implemented exclude path: http://zopewiki.org/I18nextract Could you make that patch against the trunk please? Or actually, Michael has to check it in himself, due to IP regulations. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted? We lost the username in the access.log
On Saturday 26 November 2005 17:04, Roger Ineichen wrote: We lost the user name information at the beginning of november. Any idea if we could get this information back? Yeah, I was hoping to get this done and coordinated before the release, but I did not. What we really need here is a WSGI spec change. In the short term we need to communicate with the Twisted developers (specifically James Knight) to get the user name transported via a special environment variable. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted? We lost the username in the access.log
On Tuesday 03 January 2006 10:33, Jim Fulton wrote: Did we also lose the information when using zope.server? I fear so. Yep. Has this been brought up on the Web SIG mailing list? We originally wanted to wait and try a sample implementation between Twisted and Zope 3 first. I think this was a bad idea. I'd say that that is the place to start. Right. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Handling HTTP DELETE errors
On Thursday 01 December 2005 10:31, Marius Gedminas wrote: When you do HTTP DELETE on objects that do not explicitly support deletion, the default view (zope.app.http.delete.DELETE) tries to adapt self.context.__parent__ to IWriteDirectory, which raises a TypeError which is never caught. I suggest changing the view to raise MethodNotAllowed instead when there is no adapter: +1 Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] logout patterns: a small proposal
On Thursday 08 December 2005 10:11, Gary Poster wrote: Thoughts? +1 Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted? We lost the username in the access.log
This is fairly serious, but I don't want it to delay 3.2.1 final. I suggest we try to fix this the week after the final release. I'd like to shoot for getting a 3.2.1 release out around the end of January. I'd like to see a beta release around the middle of the month. Jim Stephan Richter wrote: On Tuesday 03 January 2006 10:33, Jim Fulton wrote: Did we also lose the information when using zope.server? I fear so. Yep. Has this been brought up on the Web SIG mailing list? We originally wanted to wait and try a sample implementation between Twisted and Zope 3 first. I think this was a bad idea. I'd say that that is the place to start. Right. Regards, Stephan -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The question to configuration svn+ssh
On Monday 26 December 2005 23:38, ve le wrote: I had config ssh on subversion, but it not run Can you guide to me config? You need to provide us with more details on what's going wrong in your setup. What is the error message you got? Have you signed a contributor agreement? Have you uploaded your SSH key? Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 branches Zope-3.1 2.4 Windows 2000 zc-bbwin4
The Buildbot has detected a failed build of Zope3 branches Zope-3.1 2.4 Windows 2000 zc-bbwin4. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by '': Build Source Stamp: None Blamelist: BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] recycling testbrowser tests: a virtual hosting test hack
On Friday 16 December 2005 15:59, Gary Poster wrote: To do so, my hack makes you do two things: remove the first line of the doc test (where you import the Browser), and change your ftests.py to run the same doc test twice, once with virtual hosting, and once without. I have to do your step (1) for my tutorial runner as well; I solve it by by monkey patching the class. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Making schema configuration more modular
On Tuesday 13 December 2005 14:02, Sidnei da Silva wrote: Would anyone be against those changes? I would be okay with this abstraction, since you have provided a useful use case. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Confusion re Site Management Objects
This should have been really posted on zope3-users. On Monday 28 November 2005 00:53, Jeff Rush wrote: What are the two folders here, named 'default' and 'tools'? And why does the 'Visit default folder' link take me to the same place as clicking on the 'default' folder itself? One of the books say 'Tools folder let you manage tools.' ;-) 'Visit default folder' is just UI sugar for clicking on 'default', which is the default site management folder. It's not clear whether to create my DB connector under 'default' or 'tools' so I guessed and picked 'default'. It does not matter. You could create a third site management folder having your own custom name and place the utility (DB adapter) in there. A key part I'm confused about is that when creating the connector, I gave it a name like 'dbfinance', but later I need to register it, giving it another name. Why two names, and when is the first name ever used? The second name (registration name) is what appears in the drop-down 'Known Connectors' vocabulary. I guess I don't understand utility registration. I'm used to the Zope 2 approach of dropping DB connectors in the acquisition path. Originally we wanted to make naming and object and registering it using a name two separate concepts. I think this is still useful, but not that gentle for new comers. I agree with you that the registration form should at least suggest the name of the utility to be the registered name. After registration, I can use the connector, but I'm puzzled re access permissions. If my connector permissions is 'zope.public', for general SQL access throughout the site architecture, does that mean there is a way for anonymous website visitors to invoke arbitrary SQL operations? yes and no. Theoretically, everyone could access an arbitrary SQL expression. However, since the utility is stored inside a site management folder, the person would probably have not enough permissions to get there. Does Zope 3 support the Zope 2 idea of priviledged proxies, where an intermediate has more privilege than the user visiting the site? I do not know this Zope 2 feature, so I cannot comment. One of very useful features of Zope 2 was balloon text that popped up when you hovered over component icons within the ZMI, which told you the type of component. Adding that would help disambiguate the various types of folders, most of which have the same icon. Feel free to add the feature. Also interesting, reported as bug #494, is that you can't ever remove registered utilities via the ZMI, even when they are deactivated. You get a msg about needing to deactivate them first. ;-) Eek, I am surprised it had not been promoted to urgent. We will fix that for the next release. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] X-zope-handle-errors header
On Thursday 01 December 2005 09:28, Chris Withers wrote: Do we want Zope to always respond to this header? Yes, it's helpful for testing, but surely it risks information disclosure vulnerabilities or worse if used on a production application? The user would receive no useful information, since he would only get a SystemError page that contains null information. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
--On 29. Dezember 2005 10:08:03 -0330 Rocky Burt [EMAIL PROTECTED] wrote: Andreas Jung wrote: Another argument against removing python expressions: in Zope 2 scripters could directly modify and test templates, script etc. (also using the skins tool). In Z3 you have to restart the server at least for view classes (but not for templates). Personally I would say implement logic that allows view classes to be reloadable rather than relying on zpt for exactly this reason if this is indeed something developers need/want (I would love for such a feature). This was also one of the nice things about writing python scripts as a skins item with CMF as it was instantly reloadable. To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) -aj pgpC5PO9Jq6U4.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
Andreas Jung wrote: To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) -aj I'd go further and say regular developers should be able to develop faster with Zope 3 by having automatic reloading in most python modules in debug mode :-) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Putting pullparser and clientform where they belong (reverting 39890)
On Tue, Jan 03, 2006 at 10:51:04AM -0500, Jim Fulton wrote: Brian Sutherland wrote: On Tue, Jan 03, 2006 at 07:13:16AM -0500, Jim Fulton wrote: Because I only realized it was causing a headache for me yesterday. I greatly appreciate your working on Debian packaging. I encourage you to take time-based releases into account when doing this. You should try to create Debian based on each of our beta releases, so you don't find out late that there is a problem. Yeah, I know:( I am willing to consider a 3.2.1 release for this *after* the final. That would also be fine. OK, if you want to proceed with this, then we'll do that. Ok, I committed my patches to the trunk. Why do you think you need to do this? It is related to the debian packaging of zope 3. It is common practice with these packages to remove modules that can be provided by other debian packages. So far this has been the case only with pytz and docutils. I'm guessing that this is an issue because you install Zope's into site-packages and you don't want a Zope installed package to clobber a package that is separately packaged. Is that right? Yes, also so that if someone wants to use mechanize, they don't have to install zope3... The normal way to install Zope is in it's own directory. In this case it becomes a lot more difficult for other programs to use parts of zope (zope.interface or ZConfig comes to mind). For example, my schooltool packages can just do import zope, and it is there. No additions to sys.path necessary. In this case, a package supplied with Zope only affects Zope. In which case, I don't see the need to rip it out. In fact, I would prefer that Zope use the versions of packages that came with it, since these are the versions it has been tested with. OTOH, if you create a distribution that omits packages that are provided separately, you are taking on responsibility for assuring that the installed Zope works properly. I can understand why you would want to do this. Hopefully running the tests without the removed packages will be enough. I also try only to take these steps with code that is definitively from a different project (mechanize, pytz, docutils) and is useful in it's own right. Actually it is pretty easy to set up a debian chroot which upgrades itself and tests its Zope 3 installation every week or so. But I am missing both the time and hardware. The relevant code in the debian rules file is (yes, I know it is nasty, but there doesn't seem to be a right way): zbase= Zope-3.2.0b2 snip unpack: unpack-stamp unpack-stamp: tar xfz $(zbase).tgz mv $(zbase) z # Remove docutils and pytz modules packaged in separate packages rm -rf z/Dependencies/docutils* rm -rf z/Dependencies/pytz* I also need to do the same with mechanize and it's dependencies. Since the latest version of mechanize depends on pullparser 0.0.7, I also need to remove pullparser. This is more difficult with the way pullparser is tied into zope today. Pullparser is currently distributed within the zope.testbrowser package. It can't interfere with anything else. I suppose you just want to eliminate the duplication. No, it's worse than that. I am trying to use mechanize 0.0.11a which depends and tests for pullparser 0.0.7. Since zope includes an older pullparser and then mungs sys.modules, it causes the mechanize in site-packages to fail. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] XXX Roundup
On Friday 16 December 2005 16:20, Benji York wrote: Stephan zope/viewlet/README.txt:147 Okay, I converted this one to a TODO, which it really is. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] widget framework missing a registration?
On Tuesday 13 December 2005 05:06, Adam Groszer wrote: Is that by intention? No. Though we would need it for the set as well. Feel free to check this ion, preferably with a test. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] BBB and Deprecation Warnings
Hi all, now that we switched to time-based releases, it seems that our policy to support old API for two more 3.x releases is not appropriate anymore. Two release cycles are now only 12 months long, which seems a bit short. So let's make the deprecation support also time-based. What time would you prefer? - 12 months (2 releases) - 18 months (3 releases) - 24 months (4 releases) Note that there is a tradeoff for longer deprecation times. The longer a feature is gone, the more likely it is that you will not remember how it works and thus be unable to help people. For example, do you still remember how the old local component registry worked? I don't! :-) As a corollary, it would be time now to remove the BBB that should be removed for 3.3. Should we wait for 3.4? Or make an exception for this BBB code, since it was written before timely releases came around? Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 branches 3.2 2.4 Windows 2000 zc-bbwin
The Buildbot has detected a failed build of Zope3 branches 3.2 2.4 Windows 2000 zc-bbwin. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2550 Blamelist: benji_york,jinty,oestermeier,srichter BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
Andreas Jung wrote: --On 29. Dezember 2005 10:08:03 -0330 Rocky Burt [EMAIL PROTECTED] wrote: Andreas Jung wrote: Another argument against removing python expressions: in Zope 2 scripters could directly modify and test templates, script etc. (also using the skins tool). In Z3 you have to restart the server at least for view classes (but not for templates). Personally I would say implement logic that allows view classes to be reloadable rather than relying on zpt for exactly this reason if this is indeed something developers need/want (I would love for such a feature). This was also one of the nice things about writing python scripts as a skins item with CMF as it was instantly reloadable. To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) -aj Or at least almost as easily as in RoR or Django. TTW is not a requirement; Chris McDonough's TTB posting was right on target (http://www.plope.com/Members/chrism/ttb_programming). There are 3 PHP developers in the group I work in, and they know they want something better, and they like Python. But when they look at Z3 they get all upset confused. Is this (increased usability for non-experts) a possible project for the Zope sprint at Pycon? I'll be there. And since I am not an expert myself, I will have a head start. -- Wade Leftwich Ithaca, NY ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] BBB and Deprecation Warnings
Stephan Richter wrote: So let's make the deprecation support also time-based. What time would you prefer? I would prefer two releases and a minimum of 12 months. That way if the time-based releases slip, we still guarantee two releases with backward compatible code. If we release more often, we guarantee at least 12 months of backward compatibility. As a corollary, it would be time now to remove the BBB that should be removed for 3.3. Should we wait for 3.4? Following the rules above, if 3.3 will be released more than 12 months since the release of 3.1, it would be OK to remove the code now. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 branches 3.2 2.4 Windows 2000 zc-bbwin
[EMAIL PROTECTED] wrote: The Buildbot has detected a failed build of Zope3 branches 3.2 2.4 Windows 2000 zc-bbwin. This was apparently caused by a failed checkout. A new attempt has been initiated. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Phantom of GadflyAdapter
On Wednesday 14 December 2005 04:06, Tadashi Matsumoto wrote: I have made a test. It works well (perhaps). This test program is small, so I have attached in this mail. Thank you very much. See revision 41109. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] BBB and Deprecation Warnings
Stephan Richter wrote: On Tuesday 03 January 2006 13:33, Benji York wrote: As a corollary, it would be time now to remove the BBB that should be removed for 3.3. Should we wait for 3.4? Following the rules above, if 3.3 will be released more than 12 months since the release of 3.1, it would be OK to remove the code now. Unfortunately, Zope 3.1 *final* was not released until 10/2/2005, so that 3.3 will be out before 12 months. 12 months seems like a good interval to me, not too long to be overly burdensome on the developers, but not so short as to be overly demanding of users. As much as BBB code annoys me personally, I think maintaining a minimum compatibility window is necessary for an important class of user. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 Windows 2000 zc-bbwin3
The Buildbot has detected a failed build of Zope3 trunk 2.4 Windows 2000 zc-bbwin3. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2558 Blamelist: jim,srichter BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Benji York wrote: Stephan Richter wrote: On Tuesday 03 January 2006 13:33, Benji York wrote: As a corollary, it would be time now to remove the BBB that should be removed for 3.3. Should we wait for 3.4? Following the rules above, if 3.3 will be released more than 12 months since the release of 3.1, it would be OK to remove the code now. Unfortunately, Zope 3.1 *final* was not released until 10/2/2005, so that 3.3 will be out before 12 months. 12 months seems like a good interval to me, not too long to be overly burdensome on the developers, but not so short as to be overly demanding of users. As much as BBB code annoys me personally, I think maintaining a minimum compatibility window is necessary for an important class of user. I think 12 months is a bit short. I don't think the backward-compatibility code is that burdonsome, once written. What do other folks think? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [Patch] i18nextract implement exclude paths
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter a ?crit :
| On Tuesday 03 January 2006 05:52, Encolpe Degoute wrote:
|
|Simon Michael [EMAIL PROTECTED] implemented exclude path:
|http://zopewiki.org/I18nextract
|
|
| Could you make that patch against the trunk please? Or actually,
Michael has
| to check it in himself, due to IP regulations.
Done.
Regards,
- --
Encolpe Degoute
INGENIWEB (TM) - S.A.S 5 Euros - RC B 438 725 632
17 rue Louise Michel - 92300 Levallois Perret - France
web : www.ingeniweb.com - ? les Services Web Ing?nieux ?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDut3TvFPzBBlIZMMRAuIfAJ9jzANt8PaIvI9+en1IObn4QctUOwCfeAtL
MwCqm7JLR99hMWENuFnK5DQ=
=k5Jg
-END PGP SIGNATURE-
Index: src/zope/app/locales/extract.py
===
--- src/zope/app/locales/extract.py (révision 41114)
+++ src/zope/app/locales/extract.py (copie de travail)
@@ -123,9 +123,9 @@
self.msgid.default is not None):
default = self.msgid.default.strip()
lines = normalize(default).split(\n)
-lines[0] = # Default: %s\n % lines[0]
+lines[0] = #. Default: %s\n % lines[0]
for i in range(1, len(lines)):
-lines[i] = # %s\n % lines[i]
+lines[i] = #. %s\n % lines[i]
file.write(.join(lines))
file.write('msgid %s\n' % normalize(self.msgid))
file.write('msgstr \n')
@@ -341,6 +341,7 @@
files = []
def visit(files, dirname, names):
+names[:] = filter(lambda x:x not in exclude, names)
files += [os.path.join(dirname, name)
for name in fnmatch.filter(names, pattern)
if name not in exclude]
@@ -384,7 +385,7 @@
context = config(site_zcml, features=(devmode,), execute=False)
return context.i18n_strings.get(domain, {})
-def tal_strings(dir, domain=zope, include_default_domain=False):
+def tal_strings(dir, domain=zope, include_default_domain=False, exclude=[]):
Retrieve all TAL messages from `dir` that are in the `domain`.
# We import zope.tal.talgettext here because we can't rely on the
@@ -397,7 +398,7 @@
def write(self, s):
pass
-for filename in find_files(dir, '*.pt'):
+for filename in find_files(dir, '*.pt', exclude=tuple(exclude)):
try:
engine.file = filename
p = HTMLTALParser()
Index: zopeskel/bin/i18nextract.in
===
--- zopeskel/bin/i18nextract.in (révision 41114)
+++ zopeskel/bin/i18nextract.in (copie de travail)
@@ -40,6 +40,9 @@
-o dir
Specifies a directory, relative to the package in which to put the
output translation template.
+-x dir
+Specifies a directory, relative to the package, to exclude.
+May be used more than once.
$Id$
@@ -83,7 +86,7 @@
try:
opts, args = getopt.getopt(
sys.argv[1:],
-'hd:p:o:',
+'hd:p:o:x:',
['help', 'domain=', 'path=', 'python-only'])
except getopt.error, msg:
usage(1, msg)
@@ -92,6 +95,7 @@
path = app_dir()
include_default_domain = True
output_dir = None
+exclude_dirs = []
python_only = None
for opt, arg in opts:
if opt in ('-h', '--help'):
@@ -101,6 +105,8 @@
include_default_domain = False
elif opt in ('-o', ):
output_dir = arg
+elif opt in ('-x', ):
+exclude_dirs.append(arg)
elif opt in ('--python-only',):
python_only = True
elif opt in ('-p', '--path'):
@@ -127,18 +133,18 @@
os.mkdir(output_dir)
output_file = os.path.join(output_dir, output_file)
-print base path: %r\nsearch path: %r\ndomain: %r\noutput file: %r \
-% (base_dir, path, domain, output_file)
+print base path: %r\nsearch path: %s\nexclude dirs: %r\ndomain: %r\noutput file: %r \
+% (base_dir, path, exclude_dirs, domain, output_file)
from zope.app.locales.extract import POTMaker, \
py_strings, tal_strings, zcml_strings
maker = POTMaker(output_file, path)
-maker.add(py_strings(path, domain), base_dir)
+maker.add(py_strings(path, domain, exclude=exclude_dirs), base_dir)
if not python_only:
site_zcml = os.path.join(INSTANCE_HOME, 'etc', 'site.zcml')
maker.add(zcml_strings(path, domain, site_zcml), base_dir)
-maker.add(tal_strings(path, domain, include_default_domain), base_dir)
+maker.add(tal_strings(path, domain, include_default_domain, exclude=exclude_dirs), base_dir)
maker.write()
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2568 Blamelist: srichter BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux tlotze
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux tlotze. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2568 Blamelist: srichter BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
