Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
Brandon Craig Rhodes wrote: Tres Seaver [EMAIL PROTECTED] writes: Martijn Faassen wrote: IFoo.adapt() for normal adaptation IFoo.multiadapt() for multi adaptation I'd rather have 'adapt' take *args for the contexts, and keywords for extras (like name). And you could make the default= another possible extra! In which case our proposals at the moment compare something like this: Brandon Utility? IFoo() Single adaptation IFoo(a) ... with default IFoo(a, default=y) Multi adaptation IFoo(multi=(a,b)) ... with default IFoo(multi=(a,b), default=y) Named multi adapter IFoo(multi=(a,b), name='z') ... with default IFoo(multi=(a,b), name='z', default=y) This syntax is pretty comfortable because you get code completion for free if you are using an ide (ex. eclipse pydev). At the moment IFoo() invokes the factory of an object (if registered). IMO the current implementation is a miss-feature because you can't assign any parameters. I would prefer that IFoo() does look up the default utility and IFoo(name='z') the named one. But this change could break existing code. Martijn/Tres Utility IFoo.adapt() Single adaptation IFoo.adapt(a) ... with default IFoo.adapt(a, default=y) Multi adaptation IFoo.adapt(a,b) ... with default IFoo.adapt(a,b, default=y) Named multi adapter IFoo.adapt(a,b, name='z') ... with default IFoo.adapt(a,b, name='z', default=y) Well, I have to admit, yours are a lot prettier. The word adapt takes no more characters than my multi, and parenthesis disappear! And though I might quibble that adapt() would be better spelled utility(), there is a nice symmetry about your idea. - Both patterns make it explicit to anyone reading the code when a default value is being passed, which should vastly reduce surprise. +1 - Mine feels more natural and Pythonic to people who, like PvW in his book, think of adaptation as being like casting. +1 -- Dominik Huber Perse Engineering GmbH Alte Landstrasse 6 CH-4658 Däniken Telefon +41 56 500 01 40 Direkt +41 56 500 01 41 E-Mail [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Pagelet and LayoutTemplate recursion
On 2007-09-26 17:30:21 +0200, Stephan Richter [EMAIL PROTECTED] said: On Wednesday 26 September 2007 11:23, Christian Zagrodnick wrote: Ok. Would this break anything when z3c:template suddenly uses a different interface? I don't think so, because this is not used in Python code usually. Thanks for fixing this!! I released a z3c.tempalte 1.1a1 to downloads.zope.org and made z3c.pagelet trunk depend on it. So that problem should be gone. Would somebody test it and release it on pypi? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.form: handling of interface invariants
Am 27.09.2007 um 05:35 schrieb Stephan Richter: On Wednesday 26 September 2007 09:06, Michael Howitz wrote: This solution requests that the back-end supports non-optimistic save-points. But we can get rid of the Data class. We'll start an implementation of the second approach on a branch of z3c.form now to show if it works. I really like the second approach, if you can get it working. After thinking it over we decided to implement the first approach (change z3c.form.validator.Data to read the value of a field missing in he form on the object). We put our changes into the branch gocept-invariants. The reasons to change our decision where the following: - the second approach (using save-points) requires save-point support on the back-end and breaks without this support - using save-points would require to change the structure of z3c.form: till now the complete validation is done by z3c.form.field.FieldWidgets, using save-points validation gets split up into validation of field contents in FieldWidgets and validation of the invariants. The validation of the invariants has to be implemented at least twice: in AddForm and EditForm because saving form values is done completely different in these classes. So someone creating a direct subclass of z3c.form.form.Form has to do things again or we need additional changes in the structure. Any thoughts? -- Yours sincerely, Michael Howitz gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon: +49 345 12298898 · fax: +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
On 27 Sep 2007, at 02:29 , Tres Seaver wrote: Further, anybody who finds the effort of creating a fresh' checkout bevore making a release too burdensome should consider themselves self-selected out of the release manager pool. I'm *not* kidding about that: taking shortcuts durng the release process transfers pain / cost to everyone downstream. Amen, brother. Well said. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] faulty eggs (2)
**sigh** this morning i replaced the faulty *.zip eggs with new tar.gz releases: - zope.app.applicationcontrol - zope.app.appsetup - zope.app.session - zope.app.error - zope.error in case there are some other .zip eggs in the wild - please fix them asap. i don't blame anyone for releasing faulty eggs, but we should find a way to circumvent this in future. the working sets approach might be helpful... /me bans windows once more jodok -- If the implementation is hard to explain, it's a bad idea. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic 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: faulty releases and pypi access [update]
On 27 Sep 2007, at 04:52 , Stephan Richter wrote: On Wednesday 26 September 2007 20:35, Tres Seaver wrote: So I usually create the release first and upload it and after that create the tag. -100. Get it right, check it in, *then* upload the distribution. We do not have the tools. There is simply no telling beforehand. Marius and I worked on the ideas of a tool that he proposed earlier today. There is some telling beforehand: * As I already said, you can generate all the package metadata with python setup.py egg_info and then inspect it in src/EGG.egg-info/PKG-INFO. This is equivalent to checking the PyPI page, it contains the same information. I frequently do this, also to make sure my setup.py actually executes before I tag (I often forget a comma or so.) * You can generate an egg or a tarball locally, without uploading it. Then you can take a look at the tarball or the egg. Unzip it if necessary. Call python setup.py egg_info inside the tarball, if necessary, to see if all the CHANGES.txt, README.txt etc. files are there as well, especially when you know you messed this part up before. You could also easy_install the egg and/or tarball in a virtualenv (so that your global site-packages won't be affected). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty eggs (2)
On Thursday 27 September 2007 05:02, Jodok Batlogg wrote: this morning i replaced the faulty *.zip eggs with new tar.gz releases: They are not faulty!! There is a bug in distutils and a fix has been done in setuptools yesterday. 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: faulty releases and pypi access [update]
On Thursday 27 September 2007 05:14, Philipp von Weitershausen wrote: There is some telling beforehand: * As I already said, you can generate all the package metadata with python setup.py egg_info and then inspect it in src/EGG.egg-info/PKG-INFO. This is equivalent to checking the PyPI page, it contains the same information. I frequently do this, also to make sure my setup.py actually executes before I tag (I often forget a comma or so.) egg_info does not validate the trove classifiers, for example. I tried this last night before writing this mail. If the the setup.py file has a syntax error, I will know about it when running buildout. * You can generate an egg or a tarball locally, without uploading it. Then you can take a look at the tarball or the egg. Unzip it if necessary. Call python setup.py egg_info inside the tarball, if necessary, to see if all the CHANGES.txt, README.txt etc. files are there as well, especially when you know you messed this part up before. Still does not solve my problem use case. You could also easy_install the egg and/or tarball in a virtualenv (so that your global site-packages won't be affected). I still do not see how this solves the problem. 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: faulty releases and pypi access [update]
Hey, On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote: [snip] Further, anybody who finds the effort of creating a fresh' checkout bevore making a release too burdensome should consider themselves self-selected out of the release manager pool. I'm *not* kidding about that: taking shortcuts durng the release process transfers pain / cost to everyone downstream. While I fully agree that releases should be done with care and attention, and that doing bad releases creates pain/cost for everybody, this line of argumentation can be used to back up any form of complication to the release process. :) Let's focus on the reasons for each step and keep the discussion at that level, please? I think it's useful if people ask is that really necessary? for steps in the release process. Just weigh the pros and cons. I'd like to understand more about the trouble Philipp ran into doing releases from the original checkout and then tagging. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
Hey, I think that replacing 'index_url' with a gated community of packages is the only path to sanity here: the contract of the Cheeseshop (share new releases of all packages with everyone ASAP) is incompatible with our goals (ensure that users can install a given package and its dependencies, and have them work). Why don't you think it can be solved by having packages themselves state preferred versions? The cheeseshop can be a festering pool of madness, as long as the packages I pull from it have reasonable preferred versions, I should be fine, right? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
Hey, Tres Seaver wrote: [snip] I think that replacing 'index_url' with a gated community of packages is the only path to sanity here: the contract of the Cheeseshop (share new releases of all packages with everyone ASAP) is incompatible with our goals (ensure that users can install a given package and its dependencies, and have them work). I already replied to this, but let me point out why I think such a gated community would not be *sufficient* for my purposes. I want to be able to release package X, and have a way for other people to install it and it not break, ever. This can be done with hard version numbers in install_requires today, but people object to this reasonably as it would reduce flexibility of component reuse. If we want to have a way to reproduce installations *exactly* and we want to still allow flexibility, a gated community while hopefully increasing the quality of individual releases still won't guarantee that package X won't break when someone else tries to install it. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
Philipp von Weitershausen wrote: On 27 Sep 2007, at 13:07 , Martijn Faassen wrote: [snip] Let's focus on the reasons for each step and keep the discussion at that level, please? I think it's useful if people ask is that really necessary? for steps in the release process. Just weigh the pros and cons. I'd like to understand more about the trouble Philipp ran into doing releases from the original checkout and then tagging. I've summarized this in another thread [1], but I'll be happy to elaborate here: [snip] These are four separate cases where I've actually witnessed myself or other people mess up. We're forgetful, we can't do anything about that. We can, however, force us to catch our mistakes. I believe that if we made everybody create the tarballs from the tag, it would improve the situation a lot. I'm beginning to see a consensus that we should make it impossible to create distributions from the trunk or a release branch. Thanks, very clear. You convinced me. Even if distutils would start cleaning up after itself the other issues still stand and won't be going away. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
On 27 Sep 2007, at 12:20 , Stephan Richter wrote: egg_info does not validate the trove classifiers, for example. I tried this last night before writing this mail. Well, to be honest, I wonder how you can mess up with the classifiers. I just always copy them from http://pypi.python.org/pypi? %3Aaction=list_classifiers. Anything else is just insane... But, if you wish for such a tool, let your wish be my command. With the attached verifyclassifiers.py script, you may do so using the following command: python setup.py --classifiers | python verifyclassifiers.py If the the setup.py file has a syntax error, I will know about it when running buildout. True, but running buildout can take a long time. * You can generate an egg or a tarball locally, without uploading it. Then you can take a look at the tarball or the egg. Unzip it if necessary. Call python setup.py egg_info inside the tarball, if necessary, to see if all the CHANGES.txt, README.txt etc. files are there as well, especially when you know you messed this part up before. Still does not solve my problem use case. You could also easy_install the egg and/or tarball in a virtualenv (so that your global site-packages won't be affected). I still do not see how this solves the problem. They're measures for making sure the distribution has the right metadata and is easy_install'able. What other problem do we have? import sys import urllib2 url = 'http://pypi.python.org/pypi?%3Aaction=list_classifiers' file = urllib2.urlopen(url) valid_classifiers = file.read().splitlines() for classifier in sys.stdin: classifier = classifier.rstrip() # cut of new line at the end if classifier not in valid_classifiers: print sys.stderr, Invalid classifier:, classifier ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] pinning eggs: 'or' in version requirements
Hi there, While Jim expected to see some form of fireworks in the distutils discussion that I started about the requirement to pin down eggs while still leaving flexibility for those who want it, I think we've come to an early conclusion. Philip Eby responded and said that my use cases could be served if we could 'or' version requirements. He expects that to be in setuptools 0.7. My main use case: I want the ability to release packages that depend on other packages. I want to be able to specify exactly which versions of my dependencies I want to use in my package's setup.py. I could do this today, but then I would block any use of my package that diverged even in a minimal way by people who know what they are doing. I will give an example: Loose requirements (current practice) in setup.py: install_requires = [ 'foo',# any foo should do 'bar = 1.3', # I need a change introduced in 1.3 ] Hard requirements (but lost flexibility) in setup.py: install_requires = [ 'foo == 1.1', 'bar == 1.3.1', ] Using 'or' to combine these requirements, hypothetical syntax: install_requires = [ 'foo or foo == 1.1', 'bar = 1.3 or 1.3.1', ] Now if we taught setuptools or distutils to have a mode where it looks for the most specific in the 'or' clauses, we have a way forward, as it would get exactly those versions I said I prefer, meaning that as long as people install my package that way, it should continue to work. Of course there's the case of nested dependencies, what if I have package A which says: install_requires = [ 'B or B == 1.3', 'C or C == 1.7', ] and then a package B which says: install_requires = [ 'C or C == 1.7.1', ] which one to pick? C will do, but if we want to be specific, should we pick C 1.7 or C 1.7.1? I propose we let the outer package (A) break the contention and thus decide on C 1.7. The inner package winning would otherwise block framework packages from having the ability to make informed decisions to diverge from recommendations lower down the dependency tree. 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: faulty releases and pypi access [update]
On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote: These are four separate cases where I've actually witnessed myself or other people mess up. We're forgetful, we can't do anything about that. We can, however, force us to catch our mistakes. I believe that if we made everybody create the tarballs from the tag, it would improve the situation a lot. Of course, an additional or other approach would be to implement a tool that checks various things. I agree that the problems you listed are solvable with doing the release from the tag, but there are cases that are not caught: 1. In your last case, if bajium would have used svn switch --relocate the file would still be around and the release would work. I imagine that most people would use svn switch because making another checkout is just a package management mess. 2. My Trove classifier problem is not solved either using this approach. Contrary to what Tres hinted on in his E-mail , if there are errors while registering with PyPI, no new release is added. Also, buildout setup . egg_info does not verify the Trove classifiers. (Note that I think the Trove classifiers are only one example of something going wrong.) 3. A serious problem occurs, if you accidentally specify the wrong package name and version in setup.py. Both happened to me yesterday, but I caught it in time. A fairly simple tool can find and report all the problems found and offer assistance. I think it is worth investing in one, especially since it will reduce my overhead since my manual checking now becomes automated. 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] Re: faulty releases and pypi access [update]
Hey, On 9/27/07, Stephan Richter [EMAIL PROTECTED] wrote: On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote: [snip] A fairly simple tool can find and report all the problems found and offer assistance. I think it is worth investing in one, especially since it will reduce my overhead since my manual checking now becomes automated. Agreed a tool could be helpful in this case as well. 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: faulty releases and pypi access [update]
On 27 Sep 2007, at 13:47 , Stephan Richter wrote: On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote: These are four separate cases where I've actually witnessed myself or other people mess up. We're forgetful, we can't do anything about that. We can, however, force us to catch our mistakes. I believe that if we made everybody create the tarballs from the tag, it would improve the situation a lot. Of course, an additional or other approach would be to implement a tool that checks various things. I agree that the problems you listed are solvable with doing the release from the tag, but there are cases that are not caught: 1. In your last case, if bajium would have used svn switch -- relocate the file would still be around and the release would work. I imagine that most people would use svn switch because making another checkout is just a package management mess. Why is making another checkout a package management mess? Go to /tmp or ~/temp or whatever, get the checkout, do your release stuff and delete it again. Is this so hard? Sorry, but I fail to see how this is messy. Also, regardless of what you imagine people do, if the process says get a new, fresh checkout then this is what people should do. If they use svn switch instead, then they're not following the process. End of story. 2. My Trove classifier problem is not solved either using this approach. Contrary to what Tres hinted on in his E-mail , if there are errors while registering with PyPI, no new release is added. Also, buildout setup . egg_info does not verify the Trove classifiers. (Note that I think the Trove classifiers are only one example of something going wrong.) buildout setup? I've never seen that. I can't find any documentation on it in zc.buildout. How does it work? Does it call setup.py for every development egg in buildout.cfg? Why not just call python setup.py? Anyway, I think the Trove classifiers are an edge case. I've never seen anyone get those wrong before, to be honest. I *have* seen people get other things wrong and I think these problems would all be solved if we made it impossible to create distributions from a branch or the trunk, but made people create them from tags instead. 3. A serious problem occurs, if you accidentally specify the wrong package name and version in setup.py. Both happened to me yesterday, but I caught it in time. I assume you mean the egg name, not the package name. I'm not sure how a tool could help you here. I suppose it could use some conventions (e.g. look at the packages inside the egg) or look at the subversion URL. A fairly simple tool can find and report all the problems found and offer assistance. I think it is worth investing in one, especially since it will reduce my overhead since my manual checking now becomes automated. I'm not arguing against such a tool. If you are willing to come up with it, go for it. We should still have a proper *human* process first. A tool can then help us do the tedious bits. ___ 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: faulty releases and pypi access [update]
Philipp von Weitershausen wrote: On 27 Sep 2007, at 13:47 , Stephan Richter wrote: On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote: These are four separate cases where I've actually witnessed myself or other people mess up. We're forgetful, we can't do anything about that. We can, however, force us to catch our mistakes. I believe that if we made everybody create the tarballs from the tag, it would improve the situation a lot. Of course, an additional or other approach would be to implement a tool that checks various things. I agree that the problems you listed are solvable with doing the release from the tag, but there are cases that are not caught: 1. In your last case, if bajium would have used svn switch --relocate the file would still be around and the release would work. I imagine that most people would use svn switch because making another checkout is just a package management mess. Why is making another checkout a package management mess? Go to /tmp or ~/temp or whatever, get the checkout, do your release stuff and delete it again. Is this so hard? Sorry, but I fail to see how this is messy. Also, regardless of what you imagine people do, if the process says get a new, fresh checkout then this is what people should do. If they use svn switch instead, then they're not following the process. End of story. Release from a fresh tag check out is always good. personal I have released eggs before and after my mistake. After my mistake, I created check list for my convenience here: http://wiki.zope.org/zope3/BaijuMuthukadan An now I am making release from tag checkouts. /personal Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ChoiceField and the use of sources/vocabularies
Hi, Zagy and I are trying to make z3c.form compatible with sources. We had to investigate zope.schema for that and found the mess of vocabularies and sources that is still around. Here are some facts we found: - The Choice field has an attribute `vocabulary` which it says to be an 'IBaseVocabulary' object. - Reading the code of the choice field turns out that the actual contract is an 'ISource'. - Most client code working against the `vocabulary` attribute actually assumes it to be an IIterableVocabulary. - The vocabulary code is badly entangled and mixes up concepts that sources get right. - Widgets for the choice field have to react differently to sources and vocabularies. We think: - The contract for the `vocabulary` attribute should be ISource. - Client code (e.g. a widget) should adapt the generic source it gets to a more specific and richer interface like IIterableSource. - Widgets for the choice field shouldn't have to care for two different things that the source could be. - Vocabularies ought to die. Conclusion: We'd love to remove all traces of vocabularies from zope.schema and it more clear how to use sources. As deprecation has fallen out of favor, we wonder how to get rid of vocabularies. We definitely do not want to fork zope.schema. Would a sufficiently newer version (3.5, 4?) rectify breaking something in this way? I estimate that providing BBB is going to be a real pain. :/ Christian -- gocept gmbh co. kg - forsterstrasse 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] Why do we restrict our egg testing?
Roger Ineichen wrote: Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? I don't know what you're asking, so I can't tell you why it is wink. Why do we not use a Zope3 meta egg which contains all our zope packages as a test base. This whould allow us to test the same we have in the zope3 trunk and let us run *buildout/test -s zope* from within each egg. Perhaps because there isn't a Zope 3 meta egg. btw, what is the builbot doing right now? Does the builbot still runs test on the trunk? Or does the buildbot test the eggs? It doesn't do much of value at all right now. The transition to individual projects per package has left it behind. There are good ideas to make the buildbot work with the new setup, now we need someone to implement them. -- 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] Why do we restrict our egg testing?
On Thursday 27 September 2007 08:43, Benji York wrote: Roger Ineichen wrote: Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? I don't know what you're asking, so I can't tell you why it is wink. Why do we not use a Zope3 meta egg which contains all our zope packages as a test base. This whould allow us to test the same we have in the zope3 trunk and let us run *buildout/test -s zope* from within each egg. Perhaps because there isn't a Zope 3 meta egg. Roger is suggesting that we should have one, so that problems are detected early. Any comments on that? btw, what is the builbot doing right now? Does the builbot still runs test on the trunk? Or does the buildbot test the eggs? It doesn't do much of value at all right now. The transition to individual projects per package has left it behind. There are good ideas to make the buildbot work with the new setup, now we need someone to implement them. Right, I think this is terrible. If Roger would have not tested his package breakups against the trunk, a bunch of failures would have gone unnoticed. The power to test a base set all at once should not be underestimated. So what do people think about a pretty comprehensive Zope 3 meta egg for testing purposes? 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] ChoiceField and the use of sources/vocabularies
On Thursday 27 September 2007 08:36, Christian Theune wrote: As deprecation has fallen out of favor, we wonder how to get rid of vocabularies. We definitely do not want to fork zope.schema. Would a sufficiently newer version (3.5, 4?) rectify breaking something in this way? I estimate that providing BBB is going to be a real pain. :/ We use vocabularies exclusively. Not having BBB would be very painful for us. 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
AW: [Zope3-dev] Why do we restrict our egg testing?
Hi Benji Betreff: Re: [Zope3-dev] Why do we restrict our egg testing? Roger Ineichen wrote: Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? I don't know what you're asking, so I can't tell you why it is wink. I mean, we don't use all zope packages in our test dependency if we develop eggs. What was the reason to use a subset of of zope packages for egg testing? e.g. extras_require = dict( test = [ 'zope.testbrowser', 'zope.app.securitypolicy', 'some more zope.* packages but why not all zope.*' ], ), Why do we not use a Zope3 meta egg which contains all our zope packages as a test base. This whould allow us to test the same we have in the zope3 trunk and let us run *buildout/test -s zope* from within each egg. Perhaps because there isn't a Zope 3 meta egg. I see btw, what is the builbot doing right now? Does the builbot still runs test on the trunk? Or does the buildbot test the eggs? It doesn't do much of value at all right now. The transition to individual projects per package has left it behind. There are good ideas to make the buildbot work with the new setup, now we need someone to implement them. Is there a benefit to not depend on all zope.* packages in each egg test setup if we do a transition to indvidual packages? I understand the benefit to have smaller dependencies in eggs, but I still think a egg should run all tests we have in the zope namespace. Like we did in our old trunk setup. e.g. python test.py -s zope -pv could be now in a egg: bin\test -s zope -pv This whould allow us to run all zope.* tests during egg development. Regards Roger Ineichen -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Why do we restrict our egg testing?
Hi Betreff: Re: [Zope3-dev] Why do we restrict our egg testing? [...] So what do people think about a pretty comprehensive Zope 3 meta egg for testing purposes? +1 Tests are written for using and not ignoring them. Otherwise it means we deploy eggs wich are not tested against all zope.* packages which is a very bad idea. Regards Roger Ineichen Regards, Stephan ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: I think that replacing 'index_url' with a gated community of packages is the only path to sanity here: the contract of the Cheeseshop (share new releases of all packages with everyone ASAP) is incompatible with our goals (ensure that users can install a given package and its dependencies, and have them work). Why don't you think it can be solved by having packages themselves state preferred versions? The cheeseshop can be a festering pool of madness, as long as the packages I pull from it have reasonable preferred versions, I should be fine, right? A few things: - Your solution requires a new feature in setuptools, whose development velocity has dropped off pretty sharply of late. Maybe you've got a patch in hand already, at which point you could offer a temporary fork while the feature makes it way into an official release. - The proposed feature makes solving the package dependency graph harder, rather than easier: what if grok recommends a different version of 'zope.interface' than some other component recommends? - People do remove releases from the Cheeseshop, with various justification. If you want to guarantee that somebody will be able to recreate the known environment, even in the face of missing distributions, you have to mirror the blessed distributions. 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 iD8DBQFG+6+K+gerLs4ltQ4RAknhAJ9UHb3MWhufwJyCGQv3vhosZgFNugCeMzAB yOJcbXOmbo4Yd1OrbVF1MY0= =G7tX -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Why do we restrict our egg testing?
Roger Ineichen wrote: Hi Benji Betreff: Re: [Zope3-dev] Why do we restrict our egg testing? Roger Ineichen wrote: Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? I don't know what you're asking, so I can't tell you why it is wink. I mean, we don't use all zope packages in our test dependency if we develop eggs. What was the reason to use a subset of of zope packages for egg testing? e.g. extras_require = dict( test = [ 'zope.testbrowser', 'zope.app.securitypolicy', 'some more zope.* packages but why not all zope.*' ], ), Two things. extras are bad, and shouldn't be used, put test dependencies in the real dependencies. Second, why would you include all of the zope.* eggs if that particular package doesn't depend on them? Is there a benefit to not depend on all zope.* packages in each egg test setup if we do a transition to indvidual packages? I understand the benefit to have smaller dependencies in eggs, but I still think a egg should run all tests we have in the zope namespace. Like we did in our old trunk setup. This whould allow us to run all zope.* tests during egg development. It sounds like it would build the equivalent of the old-style Zope 3 trunk for each and every zope.* buildout. That sounds awful. Perhaps I'm misunderstanding your proposal. -- 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: AW: [Zope3-dev] Why do we restrict our egg testing?
On 9/27/07, Benji York [EMAIL PROTECTED] wrote: Second, why would you include all of the zope.* eggs if that particular package doesn't depend on them? I suspect there are hidden differences in expectations here. ;-) Roger, when you assemble an application, are you expecting to find all of zope.* in the result? We're not expecting that in the projects I'm involved in. In fact, I'd be pretty upset to find a lot of that stuff in there, and would like to see less of it than I do. Zope 3 is not an application, and I consider that a good thing. -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] Why do we restrict our egg testing?
On Sep 26, 2007, at 7:57 PM, Roger Ineichen wrote: Hi Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? It isn't practical, during development, to test all of the eggs that might be affected by a change, which is, BTW a *much* larger set than the old Zope 3 tree. For unit testing of the egg under development, there isn't much point in running other tests. For functional testing, you want to test the package's layer and, for an application a set of components that may be configured quite differently than the Zope tree. I think there is value in testing some universe in an off-line way using something like buildbot, Why do we not use a Zope3 meta egg which contains all our zope packages as a test base. This whould allow us to test the same we have in the zope3 trunk and let us run *buildout/test -s zope* from within each egg. I personally don't see much value in that, especially considering the effort involved. what is the builbot doing right now? Does the builbot still runs test on the trunk? Or does the buildbot test the eggs? Unfortunately, buildbot is a bit of a pita. :( It seems to be high maintenance. If someone wants buildbots to run, they should help or make it happen. Christian Theune has a buildbot setup that ran tests for all of the projects in the repo. I think this was *very* promising, but I don't know what the current status is. Is this a bad idea? Depends on what this is. I think running all of the tests in the old Zope 3 tree whenever we change a component is a waste of time. If this is having an automated system for testing a wide collection of packages to check for dependency breakage, then this is a great idea, but potentially a lot of work. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: AW: [Zope3-dev] Why do we restrict our egg testing?
Hi Benji Betreff: Re: AW: [Zope3-dev] Why do we restrict our egg testing? [...] Second, why would you include all of the zope.* eggs if that particular package doesn't depend on them? That's the point which I don't understand that nobody is seeing: Not my egg depends on other packages. Other package depend on the egg I develop. And tests are there for ensure that other eggs will work with my work on a specific egg. Tests are a setup of tools which can ensure that my changes are compatible with existing things. Is there a benefit to not depend on all zope.* packages in each egg test setup if we do a transition to indvidual packages? I understand the benefit to have smaller dependencies in eggs, but I still think a egg should run all tests we have in the zope namespace. Like we did in our old trunk setup. This whould allow us to run all zope.* tests during egg development. It sounds like it would build the equivalent of the old-style Zope 3 trunk for each and every zope.* buildout. That sounds awful. Perhaps I'm misunderstanding your proposal. All zope.* tests together are a way to ensure compatibility. I doesn't make sense to me not participate with all tests before a single egg get deployed. Not running all test in a namespace like we have with the zope package namspace, sounds to me that a package which doesn't like to agree on all tests should get move to another namesapce. Regards Roger Ineichen -- 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: reasonable syntax for multi-adaptation
Marius Gedminas wrote: On Wed, Sep 26, 2007 at 09:09:37PM -0400, Tres Seaver wrote: Why does the caller care? She just wants an object which will provide the 'IFoo' contract on behalf of the passed context. If 'x' is capable of providing 'IFoo' without help, then failing (or worse, returning a less-specific factory result) when calling 'getAdapter' is the Wrong Thing (a least surprise violation, if nothing else). FWIW it was a big surprise to me when I discovered that IFoo(x) has different semantics from getAdapter(x, IFoo). That's true. I spent hours debugging errors related to the adaption mechanism. The different api's and its differing lookup mechanism is only one piece in the collection of obscurities. Other pieces are caused by different frameworks that using the underlying adaption mechanism: One problem is that sometimes implemented or adapted objects got treated in different way (ex. form-framework: it's modified event notification). Another problem is that an adapted context might not locatable if its adapter does not implement ILocation or does not get location proxied implicitly (ex. local/global security). All those examples and solutions are based on assumptions about implementations and that is causing the adaption-voodoo. Lookup by interfaces and therefore the adaption asserts a higher logical abstraction layer which should encapsulate such implementation details (like adaption-, localisation- and lookup-mechanism) in a *reasonable* way. If code that relies on this abstraction has to differ the underlying mechanism and the kind of the result, it is *necessary* to provide an api that covers those needs - IOW why should the caller care or make voodoo if he gets what he wants? It would be great, if we could handle other adaption-derivations by the proposed unified, reasonable adaption-api too. Example using the IFoo()-syntax: Single adaptation IFoo(a) ... with default IFoo(a, default=y) ... assert location IFoo(a, default=y, locate=True) ... no conform-call IFoo(a, default=y, coform=False) ... force adaptionIFoo(a, default=y, force_adaption=True) ... explicit context IFoo(a, context=specific_context) Multi adaptation IFoo(multi=(a,b)) ... with default IFoo(multi=(a,b), default=y) Named multi adapter IFoo(multi=(a,b), name='z') ... with default IFoo(multi=(a,b), name='z', default=y) ... assert location IFoo(multi=(a,b), default=y, locate=True) Regards, Dominik ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: AW: [Zope3-dev] Why do we restrict our egg testing?
Betreff: Re: AW: [Zope3-dev] Why do we restrict our egg testing? On 9/27/07, Benji York [EMAIL PROTECTED] wrote: Second, why would you include all of the zope.* eggs if that particular package doesn't depend on them? I suspect there are hidden differences in expectations here. ;-) Roger, when you assemble an application, are you expecting to find all of zope.* in the result? No I excpect some of them, but others excpect others. So I'm pretty shure if we count all different setup then we can excpect all packages in the summary. We're not expecting that in the projects I'm involved in. In fact, I'd be pretty upset to find a lot of that stuff in there, and would like to see less of it than I do. That's the problem you only solve your problems with this pattern. but the zope namspace suggest participation. And you can't ensure quality wiht this point of view. Zope 3 is not an application, and I consider that a good thing. I agree, Zope 3 is not a application, but packages in this namespace can break things outside of your context. That doesn't matter if this are packages in a 3rd party namespace, but this should not happen in the zope namespace. -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] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote: ... If we are going to have a change log, which we should, I would prefer it to be included in source distributions. I want them present in the *installed* egg, not just in the source distribution: setuptools doesn't preserve source distributions after creating / installing the '.egg' version. Agreed, but Including a file other that README in the root requires extra effort that I don't want to require -- writing setup.py files is hard enough as it is. Put the real README.txt and CHANGES.txt in the actual package: the version which is a peer of 'setup.py' should be a stub which points to the real versions. I can live with this, but I don't like it. It feels more complicated to me. Jim -- Jim Fulton 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: Known working sets II [was: Eggification redux]
On Thu, Sep 27, 2007 at 10:09:23AM -0400, Jim Fulton wrote: On Sep 26, 2007, at 8:22 PM, Tres Seaver wrote: ... I think that replacing 'index_url' with a gated community of packages is the only path to sanity here: the contract of the Cheeseshop (share new releases of all packages with everyone ASAP) is incompatible with our goals (ensure that users can install a given package and its dependencies, and have them work). Regretfully, I agree. People here at ZC are already moving in this direction internally. It works for Linux distros: they periodically take packages from upstream (which would be Cheeseshop in our case) into their unstable distribution, fix incompatibilities there, then freeze and release a stable package set downloadable from a fixed URL. End users can use a stable version if they want things to Just Work, or they can install one or two packages from unstable if they really need a newer version of something, and are prepared to fix any incompatibilities themselves. Marius Gedminas -- To express oneself In seventeen syllables Is very diffic -- John Cooper Clark. signature.asc Description: Digital 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: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Tres Seaver wrote: [snip] I think that replacing 'index_url' with a gated community of packages is the only path to sanity here: the contract of the Cheeseshop (share new releases of all packages with everyone ASAP) is incompatible with our goals (ensure that users can install a given package and its dependencies, and have them work). I already replied to this, but let me point out why I think such a gated community would not be *sufficient* for my purposes. I want to be able to release package X, and have a way for other people to install it and it not break, ever. This can be done with hard version numbers in install_requires today, but people object to this reasonably as it would reduce flexibility of component reuse. If we want to have a way to reproduce installations *exactly* and we want to still allow flexibility, a gated community while hopefully increasing the quality of individual releases still won't guarantee that package X won't break when someone else tries to install it. If package 'X' points its 'index_url' to the GC, then anybody trying to install 'X' will look up / pull dependences from the GC: that setting takes the Cheeseshop completely out of play. 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 iD8DBQFG+71h+gerLs4ltQ4RAq2eAKC6MCvwyTz2e+7S9B9XmbbNccXZrwCeLCNn gzwHm/h1L8GfGkddhwS2YCI= =BpzN -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: Why do we restrict our egg testing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Thursday 27 September 2007 08:43, Benji York wrote: Roger Ineichen wrote: Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? I don't know what you're asking, so I can't tell you why it is wink. Why do we not use a Zope3 meta egg which contains all our zope packages as a test base. This whould allow us to test the same we have in the zope3 trunk and let us run *buildout/test -s zope* from within each egg. Perhaps because there isn't a Zope 3 meta egg. Roger is suggesting that we should have one, so that problems are detected early. Any comments on that? Why would we want to pull in all of Zope3 as a dependency (worse, a hidden one) before testing an egg? If the egg's dependencies are broken, I *want* the tests to fail. I don't think testing against a fat meta-egg satisfies that goal. Fix the egg so that its 'install_requires' or 'tests_requires' are sufficient to make the tests pass instead. I thought Roger was one of the folks looking to *reduce* the set of dependencies his application had on zope3 coee -- testing against the meta-egg actually makes that problem worse. 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 iD8DBQFG+78l+gerLs4ltQ4RApFIAJ9byQ03OzbOeYK8HAt+QFJMHQkxcwCdF1XJ 02Wi+nxNV3UnkNk2qaGIN6I= =r6Bz -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Why do we restrict our egg testing?
On 9/27/07, Roger Ineichen [EMAIL PROTECTED] wrote: No I excpect some of them, but others excpect others. So I'm pretty shure if we count all different setup then we can excpect all packages in the summary. If you think that testing the whole Zope 3 pile with the changed egg is something that would help, I'd suggest that's a job for a buildbot. The tests for a specific egg should test the contract for that egg. This includes a lot of things, including the effects of public ZCML files. That's the problem you only solve your problems with this pattern. but the zope namspace suggest participation. And you can't ensure quality wiht this point of view. No. When I find that a change is needed in a package, it's because it didn't fulfill it's contract. Changes to the package should include tests that the contract requires and is met by the changes. That helps everyone who depends on the contract of that package. Everything else is out of scope for that package. -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
AW: [Zope3-dev] Re: Why do we restrict our egg testing?
Hi Tres Betreff: [Zope3-dev] Re: Why do we restrict our egg testing? [...] I thought Roger was one of the folks looking to *reduce* the set of dependencies his application had on zope3 coee -- testing against the meta-egg actually makes that problem worse. Yes, I was one of the folks proposing to take more care on separating things. And I'm also proposing running all tests for a single package in a namesapce which the package is using before deployment. I think testing is overall a quality management aspect. Let me explain quality management in a abstract context. If you have a house and the target is that arround your house the tings must be clean and arrangend. You will define soemthing like: All things arround my house have to be clean and not dirty. This quality management rule will work. If you define many different things like; My carpet in front of my hous door must be clean. This whould not work. Because why, if somebody takes the carpet and brings it to a cleaning company, probably the floor under the missing carpet is dirty then. And this does not fit with your overall quality target. This is similar to our testing concept. Using small test setups for single eggs without to focus on zope as a monolitic thing will fail. Regards Roger Ineichen Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Why do we restrict our egg testing?
On Sep 27, 2007, at 10:00 AM, Stephan Richter wrote: On Thursday 27 September 2007 09:35, Jim Fulton wrote: On Sep 26, 2007, at 7:57 PM, Roger Ineichen wrote: Hi Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? It isn't practical, during development, to test all of the eggs that might be affected by a change, which is, BTW a *much* larger set than the old Zope 3 tree. I am not saying that testing *all* packages is necessary, but a healthy set of them. We did not consider this impractical when developing on the entire trunk. Back then, it was part of our development responsibility. We always ensured that some set of Zope 3 was always stable together. But we were developing the entire trunk as a whole. We were developing a monolith. For example, it was acceptable, when changing a particular Python package to fix the tests in other packages that broke by changing the tests (or the code they test) to reflect the change in the original component. This provided less than no protection to 3rd-party packages. Recently, y'all removed some files from zope.app.security. I bet you adjusted other files in the Zope 3 tree to reflect that change, but that didn't help the many more 3rd-party packages and applications that were broken. This is completely gone now. I want a solution; buildbot is okay, Good. Now we need someone to implement it. ... Depends on what this is. I think running all of the tests in the old Zope 3 tree whenever we change a component is a waste of time. I beg to differ. It has something to do with responsibility to the community. I am not saying you have to test all of Zope 3 when changing zc.* for example. But I think if a package in a defined core set is changed, requiring to run all the tests of the core set should be required. A really good example is ``zope.component``. Not testing it across several packages is very dangerous for our stability. That's a good example. The last time I changed zope.component, I *did* test it with the tree. It would be useful to be able to do that conveniently in the future. What I really want is a buildout for a big Zope 3 application, similar to what we've released in the past. Then, I will often choose to test a change in something as core as cope.component as a develop egg in that buildout. I would definitely do that. (I don't want a meta egg.) I'll note that I don't work on core components very often so testing against the Zope 3 app wouldn't be something that I would do often, but I'll concede that on those rare occasions that I do, having something like this would be useful. Jim -- Jim Fulton 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] Why do we restrict our egg testing?
On Thursday 27 September 2007 11:06, Jim Fulton wrote: What I really want is a buildout for a big Zope 3 application, similar to what we've released in the past. Then, I will often choose to test a change in something as core as cope.component as a develop egg in that buildout. I would definitely do that. (I don't want a meta egg.) Okay, so I think we simply have a clash of naming here. I think we both want the same. So how would you, technically, organize the ZMI application? I would have created an egg, which only has required packages and no code, hence I called it a meta egg. I'll note that I don't work on core components very often so testing against the Zope 3 app wouldn't be something that I would do often, but I'll concede that on those rare occasions that I do, having something like this would be useful. Right, fully agreed. 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] Grok or raw Zope?
I've posted this same message on grok-devel mailing list. I'm just looking for comments from the other side :-) Thanks a lot in advance. Hi, I'm going to start a new project in a few weeks and I'm evaluating possible frameworks to use. My best candidate at the momment is Zope 3, since I have a couple of years of experience with Python and Zope 3 provides most things I will need (such as authentication, templates, database access, workflows, etc..). We are going to build an intranet portal, where each department of the company (a software development one) has it's own area, and the application should provide applications for the needs of everyone, we need a bug tracking system, a support platform for our customers, a knowledge base for our employees and customers, an many other applications... So, I've no experience with Zope nor Grok. I would like to receive some advice about choosing Grok or Zope. I think Grok is more easy to start with, but... ¿will it in the future put any limit on a very big intranet application for an entire company? Thanks for your comments. ___ 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: Why do we restrict our egg testing?
On Thu, Sep 27, 2007 at 10:33:09AM -0400, Tres Seaver wrote: Why would we want to pull in all of Zope3 as a dependency (worse, a hidden one) before testing an egg? If the egg's dependencies are broken, I *want* the tests to fail. I don't think testing against a fat meta-egg satisfies that goal. Fix the egg so that its 'install_requires' or 'tests_requires' are sufficient to make the tests pass instead. There are two conflicting goals here: (1) testing that an egg's tests fail when its dependency list is incomplete (2) testing whether any of the other eggs that depend on this one break due to recent changes I thought Roger was one of the folks looking to *reduce* the set of dependencies his application had on zope3 coee -- testing against the meta-egg actually makes that problem worse. I think Roger wants (2). Marius Gedminas -- ...the only place for 63,000 bugs is a rain forest signature.asc Description: Digital 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: faulty releases and pypi access [update]
Hey, On 9/27/07, Jim Fulton [EMAIL PROTECTED] wrote: On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote: [snip] Including a file other that README in the root requires extra effort that I don't want to require -- writing setup.py files is hard enough as it is. Put the real README.txt and CHANGES.txt in the actual package: the version which is a peer of 'setup.py' should be a stub which points to the real versions. I can live with this, but I don't like it. It feels more complicated to me. I don't like it either. I thought we resolved this though so I'm not sure why we're discussing this. CHANGES.txt in the root dir it is, right? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, On 9/27/07, Jim Fulton [EMAIL PROTECTED] wrote: On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote: [snip] Including a file other that README in the root requires extra effort that I don't want to require -- writing setup.py files is hard enough as it is. Put the real README.txt and CHANGES.txt in the actual package: the version which is a peer of 'setup.py' should be a stub which points to the real versions. I can live with this, but I don't like it. It feels more complicated to me. I don't like it either. I thought we resolved this though so I'm not sure why we're discussing this. CHANGES.txt in the root dir it is, right? - -1. I argued for putting the CHANGES.txt and the real README.txt in the *package* dir, making them available in the *installed egg*, not just the source ditribution. 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 iD8DBQFG++AV+gerLs4ltQ4RAv11AJ48x6iioc9AWavIZS5zvQvpR/X1dwCgsuro 3CvFwTcmCfYqXFpICxDGCxk= =+T+6 -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: Known working sets II [was: Eggification redux]
Hey, On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote: [snip] Why don't you think it can be solved by having packages themselves state preferred versions? The cheeseshop can be a festering pool of madness, as long as the packages I pull from it have reasonable preferred versions, I should be fine, right? A few things: - Your solution requires a new feature in setuptools, whose development velocity has dropped off pretty sharply of late. Maybe you've got a patch in hand already, at which point you could offer a temporary fork while the feature makes it way into an official release. Yes, my solution takes time. So does setting up a gated community and making it work. Meanwhile using explicit 'versions' over a URL in buildout.cfg is a good enough hack to make it work with the cheeseshop today. - The proposed feature makes solving the package dependency graph harder, rather than easier: what if grok recommends a different version of 'zope.interface' than some other component recommends? You don't get conflicts if you use 'or'. You just get different preferred versions. The outer package wins, so Grok would win if that includes the other component. If it wants to delegate this to the other component it shouldn't specify a preferred version. - People do remove releases from the Cheeseshop, with various justification. If you want to guarantee that somebody will be able to recreate the known environment, even in the face of missing distributions, you have to mirror the blessed distributions. This is all very nice, but a gated community *don't solve my problem*. I want to be able to release something, and then have people install it with the same dependencies, and this should *never* break. A gated community will *still* feature botched new releases, upgrades to 3.5 packages that suddenly get pulled in by my package, etc. You could do this if you have a community *per project*, and the maintenance overhead goes through the roof. I want to use my 'python setup.py sdist upload'. It also yet again introduces pulls us into our own community next to the Python community, just as we started to engage with the cheeseshop. I think that would be a very regrettable development and I'm very much against it. 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] Grok or raw Zope?
Hi there. Best to post this on Zope3-users list for a response. Regards, David Matias Surdi wrote: I've posted this same message on grok-devel mailing list. I'm just looking for comments from the other side :-) Thanks a lot in advance. Hi, I'm going to start a new project in a few weeks and I'm evaluating possible frameworks to use. My best candidate at the momment is Zope 3, since I have a couple of years of experience with Python and Zope 3 provides most things I will need (such as authentication, templates, database access, workflows, etc..). We are going to build an intranet portal, where each department of the company (a software development one) has it's own area, and the application should provide applications for the needs of everyone, we need a bug tracking system, a support platform for our customers, a knowledge base for our employees and customers, an many other applications... So, I've no experience with Zope nor Grok. I would like to receive some advice about choosing Grok or Zope. I think Grok is more easy to start with, but... ¿will it in the future put any limit on a very big intranet application for an entire company? Thanks for your comments. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
Hey, On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote: [snip] I don't like it either. I thought we resolved this though so I'm not sure why we're discussing this. CHANGES.txt in the root dir it is, right? - -1. I argued for putting the CHANGES.txt and the real README.txt in the *package* dir, making them available in the *installed egg*, not just the source ditribution. Okay, I hadn't read it that way as the word 'package' is ambiguous. That seems completely against the way everybody else does this. Why is having this available in the installed egg so important? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: PLEASE don't remove eggs [was Re: [Zope3-dev] faulty releases and pypi access [update]]
Gary Poster wrote at 2007-9-26 15:47 -0400: ... So, yes, you are right, I stated an extreme position and I could be argued away from the edge. But the extremity of my position is a simple, followable rule that I certainly prefer over the case you describe. Okay, we disagree. Non working releases produce problems for most people downloading them. Thus, if they are out, and no better release is available, get rid of them such that normal users would again get the earlier, better working releases. It may hurt special users (such as maybe you). Be it. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
Raphael Ritz wrote: [snip] I don't see this in conflict. Rather as complementing each other. Yes, me too. We need human guidelines in any case. Then we implement tools to help check the human procedure. If the tool makes some of the human guidelines unnecessary as the tool catches the errors instead, then we can adjust our human guidelines to say, you can also use the tool and skip this step. It depends on what the tool will be like. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote: [snip] I don't like it either. I thought we resolved this though so I'm not sure why we're discussing this. CHANGES.txt in the root dir it is, right? - -1. I argued for putting the CHANGES.txt and the real README.txt in the *package* dir, making them available in the *installed egg*, not just the source ditribution. Okay, I hadn't read it that way as the word 'package' is ambiguous. That seems completely against the way everybody else does this. Why is having this available in the installed egg so important? Because it is a valuable clue to the guy scratching his head trying to figure out why something isn't working after 'easy_install' runs: the source distribution is only around on his system transiently. The changelog, along with the README is an essential part of the package's documentation, and should be installed with the egg. Because distutils / setuptools doesn't allow for installing non-package data, we have to put them in the package. 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 iD8DBQFG++K2+gerLs4ltQ4RAqJsAJ4io55zfVQeYWeVwDiC72/VQS7LPwCfX7sO tmi7zuaUDF3FHs9V3vpPh2w= =wnDh -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: Why do we restrict our egg testing?
Hi, I thought Christian Theune already did some work on buildbots for Zope 3 buildouts. 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: Known working sets II [was: Eggification redux]
Martijn Faassen wrote at 2007-9-26 22:13 +0200: ... I am the one who wants to have the final say in what versions of packages. I want to use. A linux distributor needs to have one working set of packages, instead. He may have one set of packages -- but he knows that not all of them work together. Moreover the set changes over time -- because new versions are released -- and finally the downloader is the one who has control over what he really installs on its local machine. Maybe, that's the equivalent to I am the one with the final say. ... We have a situation where we have developers, not maintainers, uploading new versions of packages. There will be no integrated testing done for all software built on all packages in the cheeseshop. Again, I can see similarities, but I don't believe linux distributions have *exactly* our problems solved. Our buildouts are used as development environments, not only deployment environments. Yes, we have less control over what is released on PyPI than a Linux distributor. But, you have control over what components your project depends on -- and you can select components based on underlying release care. Okay, you can also fix the dependency and thus skip careless releases... Sticking to stable versions helps, until a new stable version is released. Then all the old stuff suddenly starts using the *new* stable version, and probably break. You must have far worse experiences than I have. My components usually work across many releases with only very rare need to intervene (Five twice broke one of my products; I think that almost was it). -- 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: faulty releases and pypi access [update]
Jim Fulton wrote at 2007-9-26 18:14 -0400: ... We've just released 1.1. We guess the next release is 1.2. We change things and release, 1.2dev-r#. Someone fixes a bug and releases 1.1.1. Now there's a dev release of 1.2 that is actually older than the 1.1.1 release but that setuptools considers to be newer. I think this is fairly problematic. Then again, I think that dev releases are problematic in a lot of ways. In your example, it is likely, that the fix will also go into the 1.2 development branch. I.e. you will get an 1.2dev-r! with ! #. -- 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: faulty releases and pypi access [update]
On Sep 27, 2007, at 1:42 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-9-26 18:14 -0400: ... We've just released 1.1. We guess the next release is 1.2. We change things and release, 1.2dev-r#. Someone fixes a bug and releases 1.1.1. Now there's a dev release of 1.2 that is actually older than the 1.1.1 release but that setuptools considers to be newer. I think this is fairly problematic. Then again, I think that dev releases are problematic in a lot of ways. In your example, it is likely, that the fix will also go into the 1.2 development branch. I.e. you will get an 1.2dev-r! with ! #. I'm not sure what you mean by my example or why what you said would be so. Jim -- Jim Fulton 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] Why do we restrict our egg testing?
Stephan Richter wrote at 2007-9-27 08:55 -0400: ... Roger is suggesting that we should have one, so that problems are detected early. Any comments on that? +1 -- 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: Known working sets II [was: Eggification redux]
On Wed, Sep 26, 2007 at 08:22:48PM -0400, Tres Seaver wrote: Anybody running against the Cheeseshop today is *more* on the bleeding edge than a sysadmin whose production boxes are running 'sid': Debian has cultural constraits, even for that distro, which are vastly more restricted than the Wild West which is PyPI. The only solution I can see is to create filtered subsets / mirrors of PyPI. There is one I thought of, but it's a bit backwards. Essentially, Debian has a repository of mostly unmodified original egg tarballs. And, they've already done the hard work of maintaining sane dependencies. So, why not simply re-name the .orig.tar.gz in a Debian release repository to their original names and you have a working set corresponding to that release. If you add your selected personal working set, then you have a basis for working without bleeding. -- Brian Sutherland ___ 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: Known working sets II [was: Eggification redux]
Hey, We have a situation where we have developers, not maintainers, uploading new versions of packages. There will be no integrated testing done for all software built on all packages in the cheeseshop. Again, I can see similarities, but I don't believe linux distributions have *exactly* our problems solved. Our buildouts are used as development environments, not only deployment environments. Yes, we have less control over what is released on PyPI than a Linux distributor. But, you have control over what components your project depends on -- and you can select components based on underlying release care. Okay, you can also fix the dependency and thus skip careless releases... Exactly. I guess what I mean to say is that we're like mini distribution makers, we're not like users of distributions. Well, we're sort of both, as PyPI is a extremely messy distribution of sorts. We also typically have more than one mini distribution we maintain, while a Linux distro typically maintains only a few versions of the same large pool of packages. The selection is currently what I'm complaining about; we want stability *plus* the flexibility to deviate from this stability when we want to. Sticking to stable versions helps, until a new stable version is released. Then all the old stuff suddenly starts using the *new* stable version, and probably break. You must have far worse experiences than I have. My components usually work across many releases with only very rare need to intervene (Five twice broke one of my products; I think that almost was it). I think the problem will be reduced if you stick to stable releases. It won't go away: when a new major release of even one of the dependencies comes along, things might break. I want to avoid the whole situation of things breaking that used to work. Anyway, I think we're talking about two different topics: * better release management * my pet peeve: if I do release something today, it should work tomorrow, no matter what new releases happen of the dependencies. This should also work for frameworks where people build code on the framework I release. 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: Known working sets II [was: Eggification redux]
Hey, On 9/27/07, Brian Sutherland [EMAIL PROTECTED] wrote: [snip] There is one I thought of, but it's a bit backwards. Essentially, Debian has a repository of mostly unmodified original egg tarballs. And, they've already done the hard work of maintaining sane dependencies. So, why not simply re-name the .orig.tar.gz in a Debian release repository to their original names and you have a working set corresponding to that release. If you add your selected personal working set, then you have a basis for working without bleeding. Does it contain the Zope 3.4 eggs? Will it have Zope 3.5 eggs when we need them? I think if we're going to manage our own gated community, it'll be something we need to do ourselves. I just see the need for 1 per release of piece of software (grok 0.10, grok 0.11, etc), and only a vague idea how frameworks would work (I want to use the Foo gated community which also uses the Grok gated community) so I must be missing something. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Anybody running against the Cheeseshop today is *more* on the bleeding
edge than a sysadmin whose production boxes are running 'sid': Debian
has cultural constraits, even for that distro, which are vastly more
restricted than the Wild West which is PyPI.
The only solution I can see is to create filtered subsets / mirrors of PyPI.
snip
Exactly. Without some way to impose a gatekeeper role on the package
pool from which a given deployment draws, we can't have any
deterministic outcomes when installing packages.
OK, here is a sample gatekeeper script, intended to be run from within
a directory full of source distributions. E.g.:
$ cd /path/to/dist.example.com
$ ls
abc-1.2.3.tar.gz abc-1.2.4.tar.gz ghijk-2.3.4.tar.gz
$ python /tmp/makeindex.py *.gz
Parsing: abc-1.2.3.tar.gz
Parsing: abc-1.2.4.tar.gz
Parsing: ghijk-2.3.4.tar.gz
Project: abc
-- 1.2.3 abc-1.2.3.tar.gz
-- 1.2.4 abc-1.2.4.tar.gz
Project: ghijk
-- 2.3.4 ghijk-2.3.4.tar.gz
Assuming that the directory is the root of an Apache virtual domain,
'dist.example.com', the script creates a 'simple' subdirectory, with
an index listing the projects corresponding to the tarballs. Each
project ('abc', 'ghijk') gets a subdirectory with an index pointing to
its tarballs.
At this point, from a fresh virtualenv, you can install those packages
without risk of pulling anything from the Cheeseshop:
$ bin/easy_install --index-url=http://dist.example.com/simple ghijk
Total effort involved in maintaining the gated community then becomes
keeping a set of tarballs available at some web-downloadable location,
and re-running the script after adding / removing them to regenerate
the index.
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
iD8DBQFG/D9a+gerLs4ltQ4RAtZrAJwPrSe+vAaLTNF+XrrdyPY6bFXgTgCgzqOV
ssgeiDB9/whhld4DyylsQxA=
=f2tL
-END PGP SIGNATURE-
makeindex.py
Description: application/httpd-cgi
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
