[Zope3-dev] Re: Zope egg dependencies and tests
Christian Zagrodnick wrote: now there those wonderful eggs for Zope 3. Apart from the permission problem we ran into lately there is another one with those eggs: The dependencies aren't set right. Apparently nobody every ran the tests of those eggs. This is no wonder. When developing you need to checkout Zope 3 instead of the egg source. The Zope 3 tests would pass of course since everything is in place there. I think we should move the actual code to the eggs as soon as possible and put the externals into the Zope 3 source. Otherwise nobody ever will run the egg tests. Also we need to take care of depending on certain versions. For instance zope.location required a recent version of zope.proxy (3.3). I personally don't like these exclusive dependencies that say what you don't want. I'd rather spell it out as what I want. I think this dependency should ready =3.4. And it's definitely better to say I need 3.3 but can't find it during buildout than zope.proxy has no module named decorator somewhere when starting the application. Agreed. So, how do we get out of this? :) +1 on requiring running tests of individual projects Perhaps we could also automate this using a buildbot... -- http://worldcookery.com -- Professional Zope documentation 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] Zope egg dependencies and tests
Hey, Am Donnerstag, den 26.04.2007, 08:14 +0200 schrieb Christian Zagrodnick: Hi there, now there those wonderful eggs for Zope 3. Apart from the permission problem we ran into lately there is another one with those eggs: The dependencies aren't set right. Apparently nobody every ran the tests of those eggs. This is no wonder. When developing you need to checkout Zope 3 instead of the egg source. The Zope 3 tests would pass of course since everything is in place there. I think we should move the actual code to the eggs as soon as possible and put the externals into the Zope 3 source. Otherwise nobody ever will run the egg tests. Also we need to take care of depending on certain versions. For instance zope.location required a recent version of zope.proxy (3.3). And it's definitely better to say I need 3.3 but can't find it during buildout than zope.proxy has no module named decorator somewhere when starting the application. A related issue that I am pondering about is how to allow stable releases of a set of eggs. I definitely do not like to have to rely on only looking into a specific `find-links` server. Some issues with this: - buildout is happy to get unstable software. Is there any trigger to say: stable only please? - as we have multiple zope eggs and we only require one or two from the main application or the instance recipe (e.g. zope.app.server) we can only set the version dependency in one place (e.g. zope.app.server==3.4.0). However, then I want some gesture to say i want all zope.* packages only from the 3.4 release). This is going to be really hard when we start doing individual release numbering schemata for the eggs in the future. Additionally, I want to make sure that indirect dependencies do not pull in unstable software. I don't have any specific idea how to solve this right now. :/ Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ 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: Zope egg dependencies and tests
Previously Christian Theune wrote: Well. This depends. If you want to enable eggs to work against unstable releases then you need to do 3.3, because: 3.3 3.4dev 3.4a 3.4(.0) But =3.4dev should always work, right? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: Zope egg dependencies and tests
On 26 Apr 2007, at 09:27 , Christian Theune wrote: Am Donnerstag, den 26.04.2007, 08:40 +0200 schrieb Philipp von Weitershausen: Christian Zagrodnick wrote: now there those wonderful eggs for Zope 3. Apart from the permission problem we ran into lately there is another one with those eggs: The dependencies aren't set right. Apparently nobody every ran the tests of those eggs. This is no wonder. When developing you need to checkout Zope 3 instead of the egg source. The Zope 3 tests would pass of course since everything is in place there. I think we should move the actual code to the eggs as soon as possible and put the externals into the Zope 3 source. Otherwise nobody ever will run the egg tests. Also we need to take care of depending on certain versions. For instance zope.location required a recent version of zope.proxy (3.3). I personally don't like these exclusive dependencies that say what you don't want. I'd rather spell it out as what I want. I think this dependency should ready =3.4. Well. This depends. If you want to enable eggs to work against unstable releases then you need to do 3.3, because: 3.3 3.4dev 3.4a 3.4(.0) Maybe, but: 3.3 3.3.1 3.4dev etc. So if you just specify 3.3, 3.3.1 would satisfy this as well. And it's definitely better to say I need 3.3 but can't find it during buildout than zope.proxy has no module named decorator somewhere when starting the application. Agreed. So, how do we get out of this? :) +1 on requiring running tests of individual projects Perhaps we could also automate this using a buildbot... *yikes* I'm not very fond of buildbot at the moment as it seems extremely fragile. In this case I'm more worried about the tests getting run *at all* than managing to run them on multiple machines. Lightweight administration is the key to this problem IMHO. Yup. Low bar for contribution, too. ___ 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: Zope egg dependencies and tests
Hi, Am Donnerstag, den 26.04.2007, 11:11 +0200 schrieb Philipp von Weitershausen: Maybe, but: 3.3 3.3.1 3.4dev etc. That's right. I missed that one. :/ -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Feature freeze coming up for Zope 3.4
Hey everybody, our schedule plans the beta 1 for Zope 3.4 on 3rd of May. That's next week and it includes a feature freeze for Zope 3.4. So ladies and gentlemen: get your features wrapped up and merged. :) Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.rdb error and zope.publisher error
On Thu, Apr 26, 2007 at 02:53:54PM +0200, Maciej Wisniowski wrote: Possibly it is enough to change above code to something like: try: cursor.execute(query) except Retry: raise except ConflictError: raise except Exception, error: # Just catch the exception, so that we can convert it to a database # exception. raise DatabaseException(str(error)) Any thoughts? I would personally be in favour of just ripping out DatabaseException entirely and letting the original errors propagate. It's caused me a lot of pain in the past by hiding real problems. I have never seen any use for it. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Separating projects
The giant Zope 3 checkout / shadow project dichotomy is driving me up the wall. For code that (really) lives in the Zope 3 checkout, it's difficult to deal with separate releases for the shadow projects since the version number should really come from the Zope 3 project. I'm going to move the code for some projects from the Zope 3 tree into the separate projects, and add externals from Zope 3 to those projects. This will allow releases to be handled more sanely. The projects I'm separating are: zope.index zope.app.catalog zope.app.intid While I move the code and add externals to the Zope 3 tree, checkouts will be momentarily broken. I'll send another note when I'm done with these changes. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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: 679 Blamelist: fdrake 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] Separating projects
Yay! Is this agreed strategy once on is on the wall? :) Christian Am Donnerstag, den 26.04.2007, 14:00 -0400 schrieb Fred Drake: The giant Zope 3 checkout / shadow project dichotomy is driving me up the wall. For code that (really) lives in the Zope 3 checkout, it's difficult to deal with separate releases for the shadow projects since the version number should really come from the Zope 3 project. I'm going to move the code for some projects from the Zope 3 tree into the separate projects, and add externals from Zope 3 to those projects. This will allow releases to be handled more sanely. The projects I'm separating are: zope.index zope.app.catalog zope.app.intid While I move the code and add externals to the Zope 3 tree, checkouts will be momentarily broken. I'll send another note when I'm done with these changes. -Fred -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Separating projects
On 4/26/07, Fred Drake [EMAIL PROTECTED] wrote: While I move the code and add externals to the Zope 3 tree, checkouts will be momentarily broken. I'll send another note when I'm done with these changes. Whew! I'm done. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] yagni on overrides?
I was reading the discussion on overriding and disabling configurations here and on grok-dev and I can't help but feel that enabling overrides and trying to make them smarter or more powerful is the first step in a slippery slope towards making zcml turing complete. In grok-dev, Martijn (I think) was proposing using 'tags' in the grok directives to group parts of the configuration process together so that another package that depended on this one could enable different parts of the configuration as desired, instead of being forced to enable all or none of the grokked configuration (at least that's how I understood it). This lead me to believe that having zcml overrides is perhaps an unnecessary complexity. If I maintain a package with a set of wiring zcml directives, those that want to use my code are free to include my configuration or not, in which case they might have to repeat a large part of my zcml in their own code to make use of the parts of my configuration that was useful for them. If someone else presents me with an alternative zcml configuration for my package that was useful for their project, I can put this zcml file in my package for others to include when using it, instead of my default configuration. If there are parts in common between the default and alternative configuration, I'll refactor both configurations to make use of a common part (say, the browser cofiguration). Or maybe they're mostly the same except for some unwanted part (say, the subscriptions), then I can pull this part into a separate file that is included by my default configuration along with the other, more commonly used part. A few more iterations of these refactorings and soon enough my package will have configuration subsets that should be useful for most users of my package without requiring them to copy a significant amount of my configuration, and without requiring them to override any part of it. So, perhaps, we don't need powerful zcml overrides, just cooperative package maintainers (of which we have plenty in this community). -- View this message in context: http://www.nabble.com/yagni-on-overrides--tf3654999.html#a10211120 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: yagni on overrides?
Leonardo Rochael wrote: If someone else presents me with an alternative zcml configuration for my package that was useful for their project, I can put this zcml file in my package for others to include when using it, instead of my default configuration. If there are parts in common between the default and alternative configuration, I'll refactor both configurations to make use of a common part (say, the browser cofiguration). Or maybe they're mostly the same except for some unwanted part (say, the subscriptions), then I can pull this part into a separate file that is included by my default configuration along with the other, more commonly used part. A few more iterations of these refactorings and soon enough my package will have configuration subsets that should be useful for most users of my package without requiring them to copy a significant amount of my configuration, and without requiring them to override any part of it. So, perhaps, we don't need powerful zcml overrides, just cooperative package maintainers (of which we have plenty in this community). That assumes that (a) there are meaningful sets of configuration settings and (b) that where people want to override something, it's likely others will need the same overrides. I've seen two use cases for overrides.zcml: - Zope 2 code needing to override Zope 3 adapters to do some Zope 2-specific stuff. - Custom code that (i.e. for a specific project) that needs to change the behaviour of some standard component. In the two cases above, however, I'm not sure the assumptions hold. Having 'configuration sets', if I understand you correctly, would mean keeping two sets in sync even if they only deviate slightly. That'd be cumbersome and risk dependency upgrades breaking things. Thus, it only makes sense if there is a maintainer to look after it all. But even then it would be cumbersome. You could have some kind of inheritance mechanism, of course. My set extends your one. That's not very different from an overrides.zcml, though. I have two sets of configurations by having two overrides.zcml files and making sure only one is in use at any one time. :) When we *predict* the need for things to be overridden, we tend to make things overrideable e.g. with sensible interface modeling to allow a more specific interface override for an adapter or view, say. It's the unpredictable cases where overrides.zcml provides a useful safety valve. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Separating projects
On 4/26/07, Christian Theune [EMAIL PROTECTED] wrote: Yay! Is this agreed strategy once on is on the wall? I'm not sure I understand you question. I spoke briefly with Jim today about this issue, and he suggests that for packages that really live within the Zope3 project, they need to share version numbers with Zope3. This imposes all sorts of overhead on the various release managers for the different packages. This makes it very difficult to release the satellite projects in a non-synchronized way. For code that really lives in the satellite projects, the satellite projects own the release cycle for that code, and control their own version number. For this reason, it's better to have the code live in the satellite projects, and let the giant checkout use externals for them if it needs to. Since I expect the giant checkout to rapidly fall out of favor, I'm all for moving code to the satellite projects. Then Zope 3 will be free to become a swarm of nano-projects that can be assembled into useful but also lean and maintainable applications. Which is what we really care about. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
