Re: [Zope3-dev] Re: Removed zope.security 3.4b4
Darryl Cousins wrote: On Fri, 2007-08-17 at 19:24 +0200, Martijn Faassen wrote: I think my next step is to fix some dependencies for Grok to hard version numbers... I think that this is a good thing. I recently gave myself quite a bit grief with a careless bin/buildout which broke my application. To avoid that I need to be more specific in setup.py. (I haven't attempted it yet though). Specifying versions should be done by the application (buildout for example), not setup.py. If versions are put in setup.py they limit what others can do with the version requirements (e.g., relaxing them). I haven't noticed that any of the maintained packages on svn.zope.org have specified egg version numbers in the dependencies. (install_requires). Should perhaps example be set by beginning to do so? I prefer versions be specified (by buildout) for my packages, it helps make development a lot more deterministic. One downside is that bugs (including incompatibilities) in packages are found later because new version uptake is much slower with nailed versions. One upside, as you've discovered, is that you don't have version changes forced upon you. A nice mix of the two approaches will be possible when buildout supports the only use release eggs option. -- 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] Re: Removed zope.security 3.4b4
Hi, On Sat, 2007-08-18 at 09:16 -0400, Benji York wrote: Darryl Cousins wrote: On Fri, 2007-08-17 at 19:24 +0200, Martijn Faassen wrote: I think my next step is to fix some dependencies for Grok to hard version numbers... I think that this is a good thing. I recently gave myself quite a bit grief with a careless bin/buildout which broke my application. To avoid that I need to be more specific in setup.py. (I haven't attempted it yet though). Specifying versions should be done by the application (buildout for example), not setup.py. If versions are put in setup.py they limit what others can do with the version requirements (e.g., relaxing them). Thanks for pointing this out. I was thinking of setup.py for the (my) application, but you are right in any case. Regards, Darryl I haven't noticed that any of the maintained packages on svn.zope.org have specified egg version numbers in the dependencies. (install_requires). Should perhaps example be set by beginning to do so? I prefer versions be specified (by buildout) for my packages, it helps make development a lot more deterministic. One downside is that bugs (including incompatibilities) in packages are found later because new version uptake is much slower with nailed versions. One upside, as you've discovered, is that you don't have version changes forced upon you. A nice mix of the two approaches will be possible when buildout supports the only use release eggs option. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Removed zope.security 3.4b4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Christian Theune wrote: Hey, Am Mittwoch, den 15.08.2007, 14:15 +0200 schrieb Christian Theune: Hi, I saw the error reports about zope.security and got talked to from a few people that they had severe problems managing around this. I removed the 3.4b4 distribution from download.zope.org to allow them to continue using zopeproject and grokproject until we find a fix. I wasn't sure about that, so if someone has even worse problems now, please speak up and I'll put the package back into place again. I hope I didn't cause any more problems than exist already. Ok. As this affected more packages and Wichert found out how to deal with this in the buildout.cfg of grokproject (zopeproject and other buildout-based projects should be able to derive a workaround for this until it's fixed.) See http://paste.plone.org/16261 for the full buildout.cfg. The most important lines are 11 to 15: [app] recipe = zc.zope3recipes=0.5.3:application eggs = test zope.security==3.4.0b2 Does this mean the package won't get removed? I just prefer to use a situation where I don't get the broken egg in the first place. You're hosed, then: people are going to release eggs which break downstream applications (think libs in Debian unstable). Until we segreate the known good set away from the I just did something cool, please test set, this problem is unavoidable. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxc2b+gerLs4ltQ4RAi+UAJ9YajDGGNys1SGTNrTR3lR2oH2P4ACfeydA AkQPu0h7o0NtGAN1z8JlXxE= =2i0l -END 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: Removed zope.security 3.4b4
Hey, Does this mean the package won't get removed? I just prefer to use a situation where I don't get the broken egg in the first place. You're hosed, then: people are going to release eggs which break downstream applications (think libs in Debian unstable). Until we segreate the known good set away from the I just did something cool, please test set, this problem is unavoidable. Huh? The problem was already resolved once b5 got resolved. (removing b4 would also have resolved it for me, but I understand why this wasn't done in this case) You seem to be responding to my question on how to resolve a specific problem (broken b4 screwing up my buildouts) by telling me I can't solve the general problem? I agree we need to work on the general problem. I think my next step is to fix some dependencies for Grok to hard version numbers... Regards, Martijn ___ 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: Removed zope.security 3.4b4
Hi, On Fri, 2007-08-17 at 19:24 +0200, Martijn Faassen wrote: Hey, snip / I think my next step is to fix some dependencies for Grok to hard version numbers... I think that this is a good thing. I recently gave myself quite a bit grief with a careless bin/buildout which broke my application. To avoid that I need to be more specific in setup.py. (I haven't attempted it yet though). I haven't noticed that any of the maintained packages on svn.zope.org have specified egg version numbers in the dependencies. (install_requires). Should perhaps example be set by beginning to do so? Regards, Darryl Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/darryl%40darrylcousins.net.nz ___ 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: Removed zope.security 3.4b4
Martijn Faassen wrote: Given the momentary confusion surrounding the release of a broken package. By broken package in this case I mean something which seriously breaks many many Zope 3 installations in an obvious way. I think it might be wise to start working out some procedure surrounding such a situation. The procedure that appeals most to me is for buildout to be modified to prefer release eggs by default (the work for this has been done, and should be released soon). I also recommend projects nail their version requirements so that no matter what someone releases, they will be unaffected. This is how we run the projects I'm involved in, and it helps that we can decide, on occasion, to pay off our version debt all at once, and not have someone else create emergency work for us. * if a package is broken, the preferred route is to upload a new, fixed package with a later version number as soon as possible. (incidentally, it appears wise to verify manually that the new egg is indeed there by checking the download server.) +1 I'd therefore suggest that *if* we can't release a fixed egg for logistical reasons within a brief time-period, we proceed to remove the broken egg from the server and post a message to the mailing list saying it's broken. If buildout prefers release eggs, then only bad release eggs will cause the above problem. Coupled with nailed versions, there should be no reason for emergency communication or egg deletion. Having said that, I don't abhor the idea of an occasional purge of a bad, non-release egg. -- 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] Re: Removed zope.security 3.4b4
On 8/16/07, Benji York [EMAIL PROTECTED] wrote: If buildout prefers release eggs, then only bad release eggs will cause the above problem. Coupled with nailed versions, there should be no reason for emergency communication or egg deletion. Having said that, I don't abhor the idea of an occasional purge of a bad, non-release egg. Agreed on this (big surprise). My dislike for egg deletion is a bit stronger than Benji's, though. I'd rather see the eggs still be available, though moving them into a special busted directory is probably reasonable. -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
Re: [Zope3-dev] Re: Removed zope.security 3.4b4
Benji York wrote at 2007-8-16 08:59 -0400: ... I also recommend projects nail their version requirements so that no matter what someone releases, they will be unaffected. This is how we run the projects I'm involved in, and it helps that we can decide, on occasion, to pay off our version debt all at once, and not have someone else create emergency work for us. We discussed this some time ago. Precisely fixing the dependancies is a good thing for final applications. It is bad for components or in situations where the given application is composed from many mini-applications. -- Dieter ___ 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: Removed zope.security 3.4b4
Dieter Maurer wrote: Precisely fixing the dependancies is a good thing for final applications. +1 It is bad for components or in situations where the given application is composed from many mini-applications. I don't agree, but as long as I'm not working on your components, I don't mind. wink -- 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] Re: Removed zope.security 3.4b4
Christian Theune wrote: Hey, Am Mittwoch, den 15.08.2007, 14:15 +0200 schrieb Christian Theune: Hi, I saw the error reports about zope.security and got talked to from a few people that they had severe problems managing around this. I removed the 3.4b4 distribution from download.zope.org to allow them to continue using zopeproject and grokproject until we find a fix. I wasn't sure about that, so if someone has even worse problems now, please speak up and I'll put the package back into place again. I hope I didn't cause any more problems than exist already. Ok. As this affected more packages and Wichert found out how to deal with this in the buildout.cfg of grokproject (zopeproject and other buildout-based projects should be able to derive a workaround for this until it's fixed.) See http://paste.plone.org/16261 for the full buildout.cfg. The most important lines are 11 to 15: [app] recipe = zc.zope3recipes=0.5.3:application eggs = test zope.security==3.4.0b2 Does this mean the package won't get removed? I just prefer to use a situation where I don't get the broken egg in the first place. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
