Re: [Zope-dev] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On 2008-12-08 18:23:33 +0100, Tres Seaver [EMAIL PROTECTED] said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster [EMAIL PROTECTED] wrote: On Dec 8, 2008, at 9:02 AM, Benji York wrote: On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: Log message for revision 93722: - Switched to Zope 3.4 KGS. - New lines are no longer stripped in XML and HTML code contained in a textarea; requires ClientForm = 0.2.10 (LP #268139). This revision make the buildout fail with Error: Couldn't find a distribution for 'ClientForm=0.2.10'. I suspect you had that version of ClientForm in your cache and didn't realize that it is not available in the KGS index. Even if we fixed that, I don't want to require a particular version of ClientForm in testbrowser. There's no need to impose a newer version on people who don't need it. Anyone who does need the bug fix can specify the newer version in their project. FWIW, I disagree. The specification that you removed is exactly the sort of thing that I think is appropriate in setup.py. The tests will now fail (I assume, since I believe Christian Z added testbrowser tests for the failure caused by the ClientForm bug) with a lower version of ClientForm, so it is appropriate to set the value in setup.py. Nope, the tests will pass in the zope.testbrowser buildout. Having tests which pass only in that buildout is an attractive nuisance: I'm seeing test failures in the version of zope.testbrowser linked into the Zope2 trunk, for instance. If the behavior of zope.testbrowser is broken in the absence of a sufficiently-recent version of ClientForm, then that behavior should be spelled out in setup.py's dependencies: that is what they are for. That's the way I think of it, too. Also the bug introduced by an older ClientForm is so subtle that it is not immediately obvious that it is the testbrowser which is broken. It may if you just got an upgrade, but not if you setup your things and it just behaves strange. However, if a testbrowser user for some reason run the testbrowser tests outside of its buildout, then you're right, they may see a failure if their versions aren't new enough. At that point I would hope they would read the CHANGES.txt and see that a new version is required. The trade off is in requiring people to upgrade a dependency in order to get a bug fix that they may not care about. In the large, this is the problem with specifying versions in setup.py. Doing so assumes too much about how people are using all the dependencies involved. Here's a scenario: I fix a bug in some package, it depends on a newer version of say, zope.publisher. I put that requirement in my package's setup.py. A user of my package upgrades to get an unrelated bug fix and is forced to use the newer zope.publisher. It so happens that that the new version of zope.publisher has a different bug that bites them. They now are in a bad spot. A user of your package cannot rely on automatic dependency resolution in this case: your package is broken without the new version of its own dependency, so they can't upgrade to it. Stripping all versions from the dependencies in setup.py only works if users are willing to run their own package indexes, and figure out edge cases such as the ones you describe by themselves: at that point, forking the egg to drop the manually-resolved extra dependency is a minor nuisance. Agreed. -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
Am 08.12.2008 um 21:05 schrieb Fred Drake: [...] - add configuration support, so this can be set per-user, rather than polluting buildout.cfg for everyone. +1 I reverted the change in zc.sourcefactory. Yours sincerely, -- Michael Howitz · [EMAIL PROTECTED] · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] z3c.form 2.0 release
Am 08.12.2008 um 08:27 schrieb Stephan Richter: On Friday 05 December 2008, Martin Aspeli wrote: Is there any indication on when we'll see a 2.0 release of z3c.form? We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release. I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well and (b) the object widget is useful. Oh yes, and since I have not done the development, are we 100% test covered? There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk. But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress. [1] ... http://www.mail-archive.com/zope-dev@zope.org/msg26480.html Yours sincerely, -- Michael Howitz · [EMAIL PROTECTED] · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] z3c.form 2.0 release
Hi Michael Betreff: Re: [Zope-dev] z3c.form 2.0 release Am 08.12.2008 um 08:27 schrieb Stephan Richter: On Friday 05 December 2008, Martin Aspeli wrote: Is there any indication on when we'll see a 2.0 release of z3c.form? We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release. I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well and (b) the object widget is useful. Oh yes, and since I have not done the development, are we 100% test covered? There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk. But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress. Uhh, that's me. I will defently move the ITerms arround like proposed in this and other mails. But the leak of time is the problem. I think it should not be a show stopper. Or is it? If so I should probably do that ASAP? A dependency to zope.app.form is defently a no go for z3c.form! What do you think? [1] ... http://www.mail-archive.com/zope-dev@zope.org/msg26480.html Yours sincerely, -- Michael Howitz · [EMAIL PROTECTED] · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 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] z3c.form 2.0 release
On Tuesday 09 December 2008, Michael Howitz wrote: There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk. I would love to have this branch merged and even wait a few days with the release process. But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress. That is a real problem, as I really do not want a dependency on zope.app.form. I do not think there has been progress on the discussion, but we should just release the zope.browser package with this one interface in it for now. Another alternative would be for z3c.form to specify an ITerms interface. Porting from zope.app.form to z3c.form would be easy, since only one import would need to change. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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] z3c.form 2.0 release
Am 09.12.2008 um 11:01 schrieb Roger Ineichen: [...] There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk. But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress. Uhh, that's me. I will definitely move the ITerms around like proposed in this and other mails. But the leak of time is the problem. I think it should not be a show stopper. Or is it? If so I should probably do that ASAP? As Stephan suggested a zope.browser package with only the ITerms interface would be enough for the first step. A dependency to zope.app.form is definitely a no go for z3c.form! ACK. Yours sincerely, -- Michael Howitz · [EMAIL PROTECTED] · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Mon, Dec 08, 2008 at 10:56:15AM -0500, Benji York wrote:
On Mon, Dec 8, 2008 at 2:22 AM, Michael Howitz [EMAIL PROTECTED] wrote:
Log message for revision 93766:
color by default
This setting apparently causes problems for people who use Emacs, so
for zope. and zc. packages at least, we don't use --auto-color.
Two comments:
* on Unix it is possible to detect whether your terminal supports
color: curses.tigetnum('colors') returns 8 in gnome-terminal and -1
in emacs's dumb terminal). zope.testing.testrunner already uses
curses.tigetnum() to detect the terminal width with graceful
fallbacks on Win32 and other crippled platforms that don't have
'curses'. Making --auto-color do the Right Thing should be easy.
https://bugs.launchpad.net/zope.testing/+bug/306476
* it's a rather strong personal preference whether people want
colors or not; enabling them by default is not a good decision,
having a global config file in $HOME for that setting would be a
good choice.
https://bugs.launchpad.net/zope.testing/+bug/306478
Marius Gedminas
--
Attempts to stick to simple on-or-off options lead to monsters like gcc, which
now has so many flags that programmers are using genetic algorithms to explore
them.
-- http://www.third-bit.com/~gvwilson/xmlprog.html
signature.asc
Description: Digital 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] z3c.form 2.0 release
Am 09.12.2008 um 12:15 schrieb Roger Ineichen: [...] Should I do that tomorrow? And adjust all related packages like zope.app.form, z3c.form etc. Are there other packages which use ITerms except the one in zope.*? zc.sourcefactory, but I can migrate it myself. Christian, are you fine with this? Can you based on that merge your branch to z3c.form? Which Christian? If you mean me (I added tests to Christian Zagrodnick's branch.), I can merge it when zope.browser.interfaces.ITerms is there. Yours sincerely, -- Michael Howitz · [EMAIL PROTECTED] · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] z3c.form 2.0 release
On Sun, Dec 07, 2008 at 11:27:01PM -0800, Stephan Richter wrote: On Friday 05 December 2008, Martin Aspeli wrote: Is there any indication on when we'll see a 2.0 release of z3c.form? We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release. I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well I have an issue with this. z3c.pt.compat creates a nasty issue when trying to package it as a Debian package. The root cause seems to be that z3c.pt.compat declares z3c.pt as a namespace package. These are defined in the setuptools documentation to be merely a container for modules and subpackages. [1]. z3c.pt doesn't conform to that as it contains files. This doesn't matter till you try to install it using the --single-version-externally-managed option, at which point you get file conflicts. I've been thinking about it a while, and I think the only solution is to rename z3c.pt.compat to z3c.ptcompat, make a new release of that and migrate z3c.form. I'm willing to implement that if there's enough support. [1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages and (b) the object widget is useful. Oh yes, and since I have not done the development, are we 100% test covered? BTW, at Keas we are currently using z3c.form trunk and it all looks okay. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 ) -- Brian Sutherland ___ 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] Zope Tests: 4 OK, 2 Failed
Summary of messages to the zope-tests list. Period Mon Dec 8 12:00:00 2008 UTC to Tue Dec 9 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 8 20:29:47 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010619.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Mon Dec 8 20:31:18 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010620.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Mon Dec 8 20:23:46 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010615.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 8 20:25:17 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010616.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 8 20:26:47 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010617.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 8 20:28:17 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010618.html ___ 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] z3c.form 2.0 release
Hi Stephan, Michael, others Betreff: Re: [Zope-dev] z3c.form 2.0 release On Tuesday 09 December 2008, Michael Howitz wrote: There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk. I would love to have this branch merged and even wait a few days with the release process. But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress. That is a real problem, as I really do not want a dependency on zope.app.form. I do not think there has been progress on the discussion, but we should just release the zope.browser package with this one interface in it for now. Another alternative would be for z3c.form to specify an ITerms interface. Porting from zope.app.form to z3c.form would be easy, since only one import would need to change. Should I do that tomorrow? And adjust all related packages like zope.app.form, z3c.form etc. Are there other packages which use ITerms except the one in zope.*? Christian, are you fine with this? Can you based on that merge your branch to z3c.form? Regards Roger Ineichen Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Mon, Dec 8, 2008 at 12:23 PM, Tres Seaver [EMAIL PROTECTED] wrote: Stripping all versions from the dependencies in setup.py only works if users are willing to run their own package indexes, and figure out edge cases such as the ones you describe by themselves: The above claim appears false. Every project (both the open and closed) I work on has virtually no versions in setup.py and we don't use a private package index. We use a version section in the buildout. at that point, forking the egg to drop the manually-resolved extra dependency is a minor nuisance. Specifying your own versions requires even less work than forking. -- Benji York Senior Software Engineer Zope Corporation ___ 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] Five's implementation of Zope 3 security
All, Yuppie asked a good question on zope-cmf today: Why doesn't Five support the adapter / directive's 'permission' attribute? Or does it? The underlying discussion is that CMF trunk has a traversal namespace adapter for add forms, that looks up the actual view to render as a named adapter on (context, request, fti), because the add view needs to know the FTI to construct the object. This means that we can't use browser:page /, which means that security has to be applied manually with a ClassSecurityInfo/InitializeClass or (I presume) with a separate class require / /class block. Is there a point in supporting the 'permission' (and, presumably, 'trusted') attributes of the adapter / directive in Zope 2? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] z3c.form 2.0 release
Am 09.12.2008 um 11:06 schrieb Stephan Richter: On Tuesday 09 December 2008, Michael Howitz wrote: There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk. I would love to have this branch merged and even wait a few days with the release process. Nice. But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress. That is a real problem, as I really do not want a dependency on zope.app.form. I do not think there has been progress on the discussion, but we should just release the zope.browser package with this one interface in it for now. +1 Another alternative would be for z3c.form to specify an ITerms interface. Porting from zope.app.form to z3c.form would be easy, since only one import would need to change. -1 This does not work with other products like zc.sourcefactory which expect the interface in zope.app.form. As zc.sourcefactory has to work with zope.formlib, it can't use an interface from z3c.form to register its adapters. Yours sincerely, -- Michael Howitz · [EMAIL PROTECTED] · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] z3c.form 2.0 release
Hi Brian Betreff: Re: [Zope-dev] z3c.form 2.0 release On Sun, Dec 07, 2008 at 11:27:01PM -0800, Stephan Richter wrote: On Friday 05 December 2008, Martin Aspeli wrote: Is there any indication on when we'll see a 2.0 release of z3c.form? We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release. I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well I have an issue with this. z3c.pt.compat creates a nasty issue when trying to package it as a Debian package. The root cause seems to be that z3c.pt.compat declares z3c.pt as a namespace package. These are defined in the setuptools documentation to be merely a container for modules and subpackages. [1]. z3c.pt doesn't conform to that as it contains files. This doesn't matter till you try to install it using the --single-version-externally-managed option, at which point you get file conflicts. I've been thinking about it a while, and I think the only solution is to rename z3c.pt.compat to z3c.ptcompat, make a new release of that and migrate z3c.form. I'm willing to implement that if there's enough support. [1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages. Some distribution concept can work with this but others don't. Malthe are you aware of this? Can you change it? Regards Roger Ineichen ___ 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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Tue, Dec 9, 2008 at 9:01 AM, Gary Poster [EMAIL PROTECTED] wrote: On Dec 9, 2008, at 8:43 AM, Benji York wrote: On Mon, Dec 8, 2008 at 12:23 PM, Tres Seaver [EMAIL PROTECTED] wrote: Stripping all versions from the dependencies in setup.py only works if users are willing to run their own package indexes, and figure out edge cases such as the ones you describe by themselves: The above claim appears false. Every project (both the open and closed) I work on has virtually no versions in setup.py and we don't use a private package index. We use a version section in the buildout. The virtually is the catch here. They do have some. Yep. I maintain that we'd (or at least I) would be better off with fewer (but quite possibly not none, see below). They are typically introduced when an older version of a dependency *does not work with the software*. To me, does not work == breaks tests. Because our community, and others, try for backwards compatibility, this kind of assertion happens relatively rarely. These setup.py assertions are always, or almost always, not pinning but saying I work with X or better. I'm advocating these sorts of X or better assertions. The problem arises when your definition of works (the tests pass) conflicts with another user of the package's idea of works. Individual packages do many things for all those things to work simultaneously, then yes, the tests should pass. However, some users of that package may not need (or want) all of the things that a package does. Let me try an example. Lets say that a new version of a package (A) that I use comes out and it has some new features. Some features I would like to use, others I'm not interested in. Upon trying the new version setuptools/buildout complains that there is a version conflict because there are minimums in package A's setup.py. The new package's declared minimum for package B is higher than what I'm using, so I upgrade package B. After doing so I run my tests and find that they fail. After investigating, I find that the new version of package B has changed behavior or introduced a bug such that it is unusable for me. However, I find that if I use the previous version of package B my tests pass and the new features of package A that I want also work, then I'm happy; even though package A is broken it still works for me. I now have time to track down the problem(s) in packages A and B and reconsile them with their author(s) while still benefiting from the new features I need in package A. Of course, since the versions are specified in setup.py, I have to fork project B, so that's a little irritating. Let me re-run that scenario with no versions in setup.py: Upon trying the new version setuptools/buildout does not complain that there is a version conflict. I run my tests and find that they pass. I declare my upgrade a success and go on about my life. Someone might come back with a rejoinder that when I want to use the features of package A that don't work with the version of package B that I'm using I'll have a problem. True. Is this better or worse than the alternative? I think it's better because I only deal with version issues if I must, not just because version minimums are forced on me. I'm sure someone with a better imagination can come up with additional/better examples. Christian's zope.testbrowser change fits these characteristics. Do you, or Stephan, or anyone else with your opinions, have some other additional line that must be crossed, or do you assert that setup.py should never have any version numbers? The only time I can imagine a version number in a setup.py being a good idea is if a lower version of the dependency will have truly detrimental affects (like it has been turned into a trojan) or if every conceivable use of a package is broken without that minimum version. But even being able to import an interface is a conceivable -- and common -- use of a package, and that works no matter what version of dependencies are used (normally). For instance, if you have a project that requires a newer API in, say, zope.component, do you assert that it is inappropriate to specify a zope.component of X or better in your setup.py for that project? That sounds like something that should be documented in the CHANGES for the project, but I don't think forcing the version number is warranted even in that case (e.g. I just want to import an interface why do I have to upgrade a dependency). I wonder if the best possible world might be one in which setup.py versions are overridable by buildout's version section. That would seem to give people both options. In fact, that sounds really appealing to me. I'd like to know that a package author thinks I should use a newer version, while maintaining the option of easily ignoring their advice. I am still a little confused though. I guess people who want minimums in setup.py don't nail versions in their buildouts. (?) This
Re: [Zope-dev] z3c.form 2.0 release
2008/12/9 Roger Ineichen [EMAIL PROTECTED]: I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages. Seems to work fine for e.g. ``repoze.bfg``. Malthe are you aware of this? Can you change it? I do regret the package name and I would not be opposed to renaming it to z3c.ptcompat. \malthe ___ 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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
Hi, On Tue, 2008-12-09 at 10:28 -0500, Benji York wrote: [... -vvv ...] I wonder if the best possible world might be one in which setup.py versions are overridable by buildout's version section. That would seem to give people both options. In fact, that sounds really appealing to me. I'd like to know that a package author thinks I should use a newer version, while maintaining the option of easily ignoring their advice. I think this is the most important point in here. I think there would also be value to not *having* to care until you need. If we never specify minimum versions then I always *have* to check manually for each package and can not choose to be ignorant. I also think that it might be worthwhile to have a buildout option that will make it ignore the version specifications in the egg on request, because then: a) the requirements that the author thinks are good are documented in a well known place and in a structured manner b) the requirements can be applied by standard tools and for people who choose to ignore the issue (and are not bitten by it) c) you can still override in your case. Christian -- Christian Theune · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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] z3c.form 2.0 release
Hi, On Tue, 2008-12-09 at 12:15 +0100, Roger Ineichen wrote: [...] I do not think there has been progress on the discussion, but we should just release the zope.browser package with this one interface in it for now. Another alternative would be for z3c.form to specify an ITerms interface. Porting from zope.app.form to z3c.form would be easy, since only one import would need to change. Should I do that tomorrow? And adjust all related packages like zope.app.form, z3c.form etc. Are there other packages which use ITerms except the one in zope.*? Re-import into the old place, put BBB warnings in place without the need to have them removed immediately. At least zc.sourcefactory does and other software out in the wild. Christian -- Christian Theune · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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] z3c.form 2.0 release
On Tue, 2008-12-09 at 12:39 +0100, Michael Howitz wrote: [...] Which Christian? If you mean me [...] I hope he doesn't mean you. That would increase gocept's Christian-ratio back to 38%. SCNR. -- Christian Theune · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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] z3c.form 2.0 release
On Tue, Dec 09, 2008 at 04:31:33PM +0100, Malthe Borch wrote: 2008/12/9 Roger Ineichen [EMAIL PROTECTED]: I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages. Seems to work fine for e.g. ``repoze.bfg``. It works under most situations, but not the ones that are important to me. I've never tried to use repoze.bfg. Malthe are you aware of this? Can you change it? I do regret the package name and I would not be opposed to renaming it to z3c.ptcompat. Great, then sometime this week I'll: * rename the package * upload a release to pypi * change the imports and dependencies in z3c.form Please let me know if there's a step I'm missing? \malthe -- Brian Sutherland ___ 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] z3c.form 2.0 release
2008/12/9 Brian Sutherland [EMAIL PROTECTED]: Please let me know if there's a step I'm missing? There are other z3c.* packages which depend on it, namely z3c.template z3c.macro z3c.pagelet \malthe ___ 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] sorting ids in python
On Tuesday 09 December 2008 03:15, Andreas Jung wrote: On 08.12.2008 21:11 Uhr, robert rottermann wrote: Garry Saddington schrieb: Can anyone help me sort the following by id in a python script? for object in context.objectValues(['Folder', 'DTML Document','ZipFolder','File','Image']): objs=context.objectValues(['Folder', 'DTMLDocument','ZipFolder','File','Image']) objs.sort() for o in objs: .. huh? Afaik there is no sort order defined on a per-object basis. This is my final working solution: ids = context.objectIds(['Folder', 'DTMLDocument','ZipFolder','File','Image']) ids.sort() for object in ids: object=context.restrictedTraverse(object) path=object.absolute_url() ... . Thanks everyone Regards Garry ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] sorting ids in python
On 09.12.2008 8:45 Uhr, Garry Saddington wrote: On Tuesday 09 December 2008 03:15, Andreas Jung wrote: On 08.12.2008 21:11 Uhr, robert rottermann wrote: Garry Saddington schrieb: Can anyone help me sort the following by id in a python script? for object in context.objectValues(['Folder', 'DTML Document','ZipFolder','File','Image']): objs=context.objectValues(['Folder', 'DTMLDocument','ZipFolder','File','Image']) objs.sort() for o in objs: .. huh? Afaik there is no sort order defined on a per-object basis. This is my final working solution: ids = context.objectIds(['Folder', 'DTMLDocument','ZipFolder','File','Image']) ids.sort() for object in ids: object=context.restrictedTraverse(object) path=object.absolute_url() ... You were asking about IDs in the first place, so use objectIds(). If you are interested in the object themselves, use objectItems() as RR suggested. -aj begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:[EMAIL PROTECTED] title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] How manage error with zsql
Miguel Beltran R. wrote at 2008-12-8 21:01 -0600: I trying the next, but not work say invalid syntax (Script (Python), line 11) 2008/12/6 robert rottermann [EMAIL PROTECTED] hi, I think you should write in a python script: try: result = context.insert_data.zsql msg = 'data inserted' except StandardError as e: -- error here The as should be , instead. After the removal of this error, you will meet the next two, I have already pointed out in a message sent yesterday. ... If change to try: result=context.proyecto_alta_zsql() msg=Se incertaron los datos correctamente except StandardError, (e1,e2): msg = Error valor %s y %s % (e1,e2) return msg say Tipo: Unauthorized Valor: You are not allowed to access 'a particular str' in this context Already much better :-) In exceptional cases, the (e1, e2) might work. However, usually, exceptions are no sequences and an exception cannot be matched with (e1, e2). Try except StandardError, e: (and, of course, change the following line accordingly). Whenever you get exceptions, you should look at the error description in your error_log object (in the Zope Root Folder of the ZMI). There, you can see (in the so called traceback) where the exception has been raised. This is invaluable information. Usually, error_log ignores Unauthorized. Therefore, you must temporarily reconfigure the error_log in order to get the information. Should you have problems to understand it, come back with the information. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] How manage error with zsql
Whenever you get exceptions, you should look at the error description in your error_log object (in the Zope Root Folder of the ZMI). There, you can see (in the so called traceback) where the exception has been raised. This is invaluable information. -- Dieter Thanks, another question is possible have a general except and inside show what type is? in dtml was dtml-try ... dtml-except type:dtml-var error_type value: dtml-var error_value /dtml-try -- Lo bueno de vivir un dia mas es saber que nos queda un dia menos de vida ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
