Re: [Zope3-dev] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
On Tuesday 02 October 2007 17:14, Jim Fulton wrote: > One hole I see is giving people guidance on what needs to be tested > (and how) before a release is made. My preference would be to rely > heavily on judgement with a few checks so as not to make things too > heavy. This might rule out some releasers. I want tools! Actually, I just want one tool. 70% of the release process is repetition and that needs to be factored into a tool. This tool should have been written before the Zope trunk was blown into pieces, but it wasn't. :-( There is no way that we will be able to support this many packages in the future, if we keep doing this manually. I have already spent days on doing eggs, when I really just wanted to code. :-( Marius and I wrote down some notes what such a tool could do. I hope he will post them here. 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: New package zc.configure provides an exclude directive for excluding zcml files
Jim Fulton wrote: On Oct 2, 2007, at 3:29 AM, Martijn Faassen wrote: Jim Fulton wrote: [snip] Maybe grok was already trimmed down. In my case, I basically eliminated all ZMI support (since I didn't need it). I got about 40%, Grok is trimmed down in the sense that it doesn't depend on all Zope 3 packages, though due to the interesting dependency structure it still relies on about 100 eggs. We didn't do any trimming down of ZMI support. Note that it wasn't my goal to trim the number of eggs I got, although trimming that, or, in theory, using zipped eggs would speed startup as well. I'm using the zope.app.zcmlfiles egg as my base. Would it be possible to get a list of exclude statements that you use to eliminate ZMI support in your project? I imagine our list is far from complete. Here is the zcml file I'm including rather than incliding zope.app.zcmlfiles/configure.zcml: [snip] +1 to that approach. I think in the long term, egg-based Zope application should want to get away from zope.app.zcmlfiles In particular, zope.app.zcmfiles is the epitome of the ZMI app: it loads all the browser stuff and configures the zmi_actions + zmi_views menu. Not loading zope.app.zcmlfiles but instead selectively loading only the stuff we need will likely reduce the ZCML processing time as well. Death to zope.app.zcmlfiles! -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: major packaging reorganization happening in 3.4releases?
Roger Ineichen wrote: On 02.10.2007, at 14:25, Jim Fulton wrote: On Oct 2, 2007, at 5:25 AM, Martijn Faassen wrote: Hi there, Besides causing us a lot of problems here at the Grok sprint, I also wonder why in the world are we doing major packaging reorganizations and releasing them as minor 3.4.x releases? You'd think such a reorganization would warrant a 3.5 release! Sorry, I can't resist to answer the question with some black humor: I don't know, probably ask the release manager. Ah, right, we do not have a releas manager anymore since all developer have to release their eggs by itself. Sorry, but blaming this on the eggification is just a cheap shot. We *do* have a release manager for 3.4. His name is Christian Theune. He wrote a wiki page [1] that specifically spells out instructions for release 3.4.x. eggs. And the 3.4.x eggs are in *stabilization*, as the wiki page accurately says. Stabilization does *NOT* imply moving stuff around like you did. This is 3.5.x business. Again, don't take it personal! I'm not pointing with my finger to anybody. I just point my finger on the situation we have right now. I'm much in favour of the work you're doing (separating pure Python components from their browser views). But with all due respect, Roger, all you've been doing right now is pointing your finger at this situation. I think a more constructive point of view would be looking at how we can *improve* this situation. Let's hear it: what's *your* suggestion? But what does slowdown mean? Do we need to slowdown the development or do we have to slowdown releasing eggs? I *think* that Jim means slow down refactoring things and moving things around. Releasing already *stable* stuff is perfectly ok. Or do we need to slow down till we have a better development process or tools? If so, can we make progress on that? We should definitely discuss the development process. I've tried to write down some rules [2]. Let's discuss those. Let's improve them. Let's stick to them in the future. The last two weeks have given us perfect examples of what NOT to do. I think we can all agree on that. Most of could've been avoided if the process had been followed. At this point, I don't really care much about what the process is, as long as it's clear, reliable and easy to follow. [1] http://wiki.zope.org/zope3/StabilizeEggPackages [2] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
On Oct 2, 2007, at 5:05 PM, Philipp von Weitershausen wrote: Martijn Faassen wrote: A release of zope.dottedname was made apparently today that refers to a CHANGES.txt but doesn't have one. Probable scenario: someone forgot to svn add a CHANGES.txt, then didn't check out before the tag before releasing... Right. This is actually a *common* mistake. Not everybody believed me when I sad that it was. I think we've got proof of this once more now. A couple of days ago I added some very explicit instructions on how you should make a release to my guide [1]. Basically it says you should *first* make a tag and only create the release *from the tag*. I hope that people will take this more seriously now. I do, It's not that I consider my guide to be a papal edict (I'm not Jim, after all), :) It would help if you would split out the release making part so we can focus on that. but it *is* based on experience and best practices. Having made releases for many Zope eggs (if you want proof, just look at [2]), I think I can safely say that I know my way around the pitfalls now. Agreed. That said, I welcome any suggestion that other people have while creating releases. We need to get better at this stuff! Yup. See above about separating the release instructions. One hole I see is giving people guidance on what needs to be tested (and how) before a release is made. My preference would be to rely heavily on judgement with a few checks so as not to make things too heavy. This might rule out some releasers. 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
[Zope3-dev] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
Martijn Faassen wrote: A release of zope.dottedname was made apparently today that refers to a CHANGES.txt but doesn't have one. Probable scenario: someone forgot to svn add a CHANGES.txt, then didn't check out before the tag before releasing... Right. This is actually a *common* mistake. Not everybody believed me when I sad that it was. I think we've got proof of this once more now. A couple of days ago I added some very explicit instructions on how you should make a release to my guide [1]. Basically it says you should *first* make a tag and only create the release *from the tag*. I hope that people will take this more seriously now. It's not that I consider my guide to be a papal edict (I'm not Jim, after all), but it *is* based on experience and best practices. Having made releases for many Zope eggs (if you want proof, just look at [2]), I think I can safely say that I know my way around the pitfalls now. That said, I welcome any suggestion that other people have while creating releases. We need to get better at this stuff! [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt [2] http://wiki.zope.org/zope3/StabilizeEggPackages -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] major packaging reorganization happening in 3.4releases?
Hi all > Betreff: Re: [Zope3-dev] major packaging reorganization > happening in 3.4releases? > > > On 02.10.2007, at 14:25, Jim Fulton wrote: > > > > > On Oct 2, 2007, at 5:25 AM, Martijn Faassen wrote: > > > >> Hi there, > >> > >> Besides causing us a lot of problems here at the Grok > sprint, I also > >> wonder why in the world are we doing major packaging > reorganizations > >> and releasing them as minor 3.4.x releases? You'd think such a > >> reorganization would warrant a 3.5 release! Sorry, I can't resist to answer the question with some black humor: I don't know, probably ask the release manager. Ah, right, we do not have a releas manager anymore since all developer have to release their eggs by itself. I think this question/answer describes our problem very well we have now. Again, don't take it personal! I'm not pointing with my finger to anybody. I just point my finger on the situation we have right now. > > Agreed. Someone needs to sloow down. "Speed kills." > deserves to > > be added to the Zen of Python. (Actually, ZoP does have a > variation of > > that.) > > +100. > that was the most unproductive week in lovely systems HQ ever. I agree, but that's another topic... ...and probably I'm the person to blame. But what does slowdown mean? Do we need to slowdown the development or do we have to slowdown releasing eggs? Or both? Or do we need to slow down till we have a better development process or tools? If so, can we make progress on that? Regards Roger Ineichen > jodok > > > > > Jim > > > > -- > > Jim Fulton > > Zope Corporation > > > > > > ___ > > Zope3-dev mailing list > > Zope3-dev@zope.org > > Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% > > 40lovelysystems.com > > > > -- > "Beautiful is better than ugly." >-- 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 > > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] major packaging reorganization happening in 3.4 releases?
On 02.10.2007, at 14:25, Jim Fulton wrote: On Oct 2, 2007, at 5:25 AM, Martijn Faassen wrote: Hi there, Besides causing us a lot of problems here at the Grok sprint, I also wonder why in the world are we doing major packaging reorganizations and releasing them as minor 3.4.x releases? You'd think such a reorganization would warrant a 3.5 release! Agreed. Someone needs to sloow down. "Speed kills." deserves to be added to the Zen of Python. (Actually, ZoP does have a variation of that.) +100. that was the most unproductive week in lovely systems HQ ever. jodok Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- "Beautiful is better than ugly." -- 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
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 26, 2007, at 6:14 PM, Jim Fulton wrote: ... I agree that the develop egg case is problematic. I'd like to think about that. Well, I thought and I thought I could probably arrange that develop eggs created by buildout got their versions from the buildout spec. Something like: [buildout] develop = . ==1.4 foo ==2.1 This would override whatever version was given in setup.py. This wouldn't help people who don't develop with buildout though. Alternatively, we could add some API that would allow our setup files to take a --version argument. So our setup files on the trunk or branches might have something like: setup( version = comman_line_version() or something. I'm not an expert on extending setuptools. I'm somewhat pessimistic about getting new features in setuptools as 0.7 seems to have fairly grandiose objectives. There don't seem to be incremental feature releases planned. :( I have a feeling that we/I should learn how to extend setuptools to get the features we need. 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: faulty releases and pypi access [update]
On Sep 27, 2007, at 8:00 AM, Philipp von Weitershausen wrote: ... buildout setup? I've never seen that. I can't find any documentation on it in zc.buildout. G. Sure enough, the documentation doesn't mention it. That's an annoying documentation bug, I'm pretty sure it was documented at one time. Also, some examples in the documentation use it. How does it work? bin/buildout setup setup arguments ... Does it call setup.py for every development egg in buildout.cfg? No. Why not just call python setup.py? Because: - The setup you are invoking uses setuptools and you are using a clean Python, or - The the setup.py you're using doesn't use setuptools but you want to use setuptools commands. Basically, the setup command is a convenience that gets setuptools into the path and imported before invoking the given setup. I find this quite useful. One annoyance is that, although there are workarounds, it generally wants there to be a buildout.cfg file around and I often want to use it to run a setup.py that has nothing to do with a buildout. 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
[Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 27, 2007, at 7:37 AM, Philipp von Weitershausen wrote: 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... The classifiers are a PITA. I suspect we should be very restrictive in using them. It's especially annoying that release status can generally be inferred from the version number. I'm beginning to wonder if we should have some setuptools extensions that automate some of these things, Another idea I've been thinking about is a custom index that is used rather than PyPI. The main motivation was to automate management of non-public distributions, but such a front end could also automate some aspects of releases that setuptools doesn't handle. 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 Cool. 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
[Zope3-dev] zope.dottedname doesn't have a CHANGES.txt (again?)
Hi there, A release of zope.dottedname was made apparently today that refers to a CHANGES.txt but doesn't have one. Probable scenario: someone forgot to svn add a CHANGES.txt, then didn't check out before the tag before releasing... This is like the third time Grok (trunk *and* the 0.10 release) broke during this sprint alone. 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 Sep 27, 2007, at 7:18 AM, Philipp von Weitershausen wrote: On 27 Sep 2007, at 13:07 , Martijn Faassen wrote: 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. I've summarized this in another thread [1], but I'll be happy to elaborate here: * People actually forget to make the tag. This happened to Roger the other day. It happened to Jim before with zc.buildout. I'm not mentioning their names to point fingers. I'm just pointing out that people who've been with us for a long time forget. If the process said they should actually check out the tag, they'll hardly forget. Having a script we have to mindlessly follow will help. * People create the wrong tags or tags in the wrong places. This happened to Jim the other day with ZODB 3.7.1. Again, I'm not blaming him. But I believe if he had to check out the tag to make the release, he would've caught his mistake. I doubt it. I would have probably just rereleased 3.7.1, possibly with 3.7.2 uselessly included. * People forget to clean up the 'build' directory. This happened to me the other day. Let me elaborate: I have a trunk checkout of zopeproject that I use to develop it. Whenever I wanted to make a release, I'd just prepare it, tag it and generate the distributino from the trunk checkout. The problem was that I had moved stuff around, but the old stuff was still making it to the egg because it still sat around in the 'build' direcdtory that distutils leaves. I know it sucks that distutils doesn't clean up after itself, but that's just the way it is. If you're forced to use a clean checkout, this can't happen. The build directory is really annoying. * People forget to check in important files. This happened to Baiju the other day. He created a CHANGES.txt file and referred to it from setup.py. The only problem is that he forgot to check it in. It can happen, I'm not blaming him. The problem is that setuptools looks at which files are in svn in order to create the archive manifest. So CHANGES.txt wasn't in the tarball and the egg was completely uninstallable (because setup.py couldn't be executed since CHANGES.txt was missing). 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. Yup. BTW, I find it helpful to test source releases by unpacking them and seeing if I can build eggs from the unpacked source. Of course, it would be even better to run the tests. I suspect that a buildout feature could automate this. Something along the lines of a buildout command that: creates distros from the listed develop directories and then installs those distros rather than the develop eggs so that tests could be run against the distros. This would probably be something good to do when I have some time to get back to buildout. 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
[Zope3-dev] Re: faulty releases and pypi access [update]
On Sep 27, 2007, at 4:45 AM, Philipp von Weitershausen wrote: 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. +1 -- 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
[Zope3-dev] Couldn't install zope.dottedname-3.4.1
Hi together, looks like zope.dottedname-3.4.1 is broken. [snip] Getting distribution for 'zope.dottedname'. error: /tmp/easy_install-mLVo5d/zope.dottedname-3.4.1/CHANGES.txt: No such file or directory An error occured when trying to install zope.dottedname 3.4.1.Look above this message for any errors thatwere output by easy_install. While: Updating anyband-app. Getting distribution for 'zope.dottedname'. Error: Couldn't install: zope.dottedname 3.4.1 [snip] Regards, Tobias ___ 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]]
On Sep 26, 2007, at 10:35 AM, Jim Fulton wrote: This is also a technical issue: As long as zc.buildout and setuptools foolishly accept dependency links from an egg, it'll be painful to detect accidental reliance on external repositories. That's a good point. I wouldn't go so far as to say "foolishly", but I would say that this is a policy that should be overrideable. Checkins to buildout (with tests, of course) accepted. Sort of that, a feature request in launchpad would be helpful so this idea doesn't get forgotten. 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: faulty releases and pypi access [update]
On Sep 28, 2007, at 1:36 PM, Dieter Maurer wrote: ... Your example: You have release 1.1. You start working on the next release: 1.2dev-r#. Someone fixes a bug in 1.1 and releases 1.1.1. With quite high probability, the bug fix should go as well into the 1.2 development. Thus, the problem you describe (1.1.1 is newer than 1.2dev-r; but it treated as older then 1.2dev by 'setuptools') has an effect only for a very limited time -- the time until the fix (1.1 --> 1.1.1) went into the 1.2dev release, which would probably become some 1.2dev-r!. Sure, but that time could stretch out quite a bit. I suppose that this problem somewhat inherent in having multiple release branches. For example, whatever we do, there will always be the possibility that an x.y.z release could have fixes in it that aren't in an x.y+1 release yet, especially if x.y is a non-final release. 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: AW: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
On Oct 2, 2007, at 9:24 AM, Roger Ineichen wrote: Hi Jim, Betreff: Re: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors. [...] Yes, please do. It's up to people making changes to use some judgement. I mentioned in that thread that when I make changes to "core" components, I often do test against the old trunk tree. Despite all of your complaints about the need to do this, you didn't. That's not true. I did test the package against the trunk. But the problem was, I also adjusted the imports in the packages. hehe. This sort of practice makes any arguments for testing against the "trunk" kind of meaningless. What I was missing is to run the tests against a older version of the trunk. So perhaps now you want people to test against old versions of the trunk? How many old versions? A better approach would have been to add backward compatibility tests for each backward-compatibility support change you made, as Lennart suggested. Even then, to be more sure that you caught everything, you should have made the changes in two stages: 1. Refactor the package in question providing backward compatibility support, including tests of that support. Test against other unchanged packages. 2. Then change the other packages is you must. ... I know there is no difference between the old trunk and the new egg development testing. This error whould also happen to me if I where doing it in the old trunk setup. My problem was not test my work against a older version of the trunk. Or like Lennart told, the missing tests for integration (import changes). The latter. The 2-step process that we've used in the past would also have helped. I personaly think, less test -- more errors. So test! What's stopping you? The old tree is still available! The crapy "do it by your self test setup" is stopping me really hard or at least slowing me down right now more then the it should. Maybe it should slow you down more. It's not easy to follow all the ideas behind egg, setuptools, easy_install, buildout in such a speed like we changed to this patterns. I agree "Speed kills", but I think switch to eggs force us to "take it all or nothing". We probably do need more formalized testing/release methodologies. As I'm sure Tres and others will rightly point out, there's probably a lot we can learn in this area from linux distributors. In the mean time, changing packages that lots of other people depend on requires judgement and care. If you don't think you're up to it, then don't try it. 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] zope.app.securitypolicy deferred imports errors.
Hi Jim, > Betreff: Re: AW: [Zope3-dev] zope.app.securitypolicy deferred > imports errors. [...] > Yes, please do. It's up to people making changes to use some > judgement. I mentioned in that thread that when I make changes to > "core" components, I often do test against the old trunk tree. > Despite all of your complaints about the need to do this, you didn't. That's not true. I did test the package against the trunk. But the problem was, I also adjusted the imports in the packages. What I was missing is to run the tests against a older version of the trunk. [...] > Most people aren't changing these components. Nevertheless, we still > have the old tree available for testing. We didn't lose anything. I can agree with, we didn't loose anything. So let's say it's not just there anymore. > > And this is a very bad idea. If we don't recommend to run > > all tests again form a single egg refactoring, we will > > see more errors like this. > > Don't you think it's a little hypocritical bemoaning that we're not > doing this when you don't do it yourself? Again, I did run the tests against the runk, but I didn't recognize that I should test my changes against a older version of packages. Probably I'm not that smart to take care on everything and was trusting on testing to much ;-) I know there is no difference between the old trunk and the new egg development testing. This error whould also happen to me if I where doing it in the old trunk setup. My problem was not test my work against a older version of the trunk. Or like Lennart told, the missing tests for integration (import changes). > > I personaly think, less test -- more errors. > > So test! What's stopping you? The old tree is still available! The crapy "do it by your self test setup" is stopping me really hard or at least slowing me down right now more then the it should. It's not easy to follow all the ideas behind egg, setuptools, easy_install, buildout in such a speed like we changed to this patterns. I agree "Speed kills", but I think switch to eggs force us to "take it all or nothing". Regards Roger Ineichen [...] > Jim > > -- > Jim Fulton > 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] Re: AW: AW: Re: AW: Are pagelets content providers?
Hi Thomas > Betreff: [Zope3-dev] Re: AW: AW: Re: AW: Are pagelets content > providers? > > Roger Ineichen wrote: > > > Yes you are right, that was the reason I didn't define the __init__ > > method in the interface. But I still think a IPagelet isn't a > > IContentProvider by default. Of corse another class can be > defined as > > IContentProvider and IPagelet. Such a class whould then provide a > > different __init__ method then the pagelet does right now. > > See my other response I wrote before I read this message of yours. As longer as I think about your idea, you are probably right. I agree with not declaring __init__ in the interface. That's what we did. The only concren I have right now with IPagelet is inherited from IContentProvider is the default TALES expression which uses the following code for lookup IContentProvider: class TALESProviderExpression(expressions.StringExpr): ... # Try to look up the provider. provider = zope.component.queryMultiAdapter( (context, request, view), interfaces.IContentProvider, name) ... This requieres a specific __init__ method. What do you recommend to do? I'm open to improve it but how can we reflect the different adaption concepts like we have with the different __init__ used by IPagelet and IContentProvider. I agree that __init__ is not a part of the interface. But I also think it should be a part of a (probably another) interface since this is required by a specific lookup pattern. But that's probably over designed. Any idea? > > Should we implement a z3c.form/z3c.pagelet package? There we could > > support z3c.form base classes built up on pagelets. > > > > Probably called z3c.formpagelet which contains IPageletForm, > > IPageletAddForm etc. > > This would solve my use case but sounds like a lot of > architecture, to be honest. I think this is exactly what I > hoped to avoid by pinning the internal communication between > pagelets and pagelet renderers down to talking > IContentProvider and thereby allowing pagelets to be used as > content providers from everywhere. See the "dead chicken" > remark in my first reply to you. Ok, I see your idea Regards Roger Ineichen > -- > Thomas > > > > ___ > 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
Re: AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
On Oct 2, 2007, at 6:03 AM, Roger Ineichen wrote: Hi Lennart Betreff: [Zope3-dev] zope.app.securitypolicy deferred imports errors. Roger Inechens split of zope.app.securitypolicy into zope.securitypolicy cause loads of problems, because many of the deferred imports were incorrect. I saw Stefan Richter fixed some, and I have fixed some more. Yes you are right First somebody that can make releases (which may or may not include me, I honestly don't know who can make releases of eggs) needs to make a new one. But we also need to avoid this stuff in the future. Yes, we always have to avoid errors, but sometimes it happens. And since we dont test against the trunk, we don't see this kind of errors anymore. This means we test against custom projects. I didn't fully recognize this and was trusting the tests. But I was wrong. We don't have tests for this anymore. We probably didn't have test for my error at all. In other words; Right now we only test if a egg works within their dependency. But we don't test other eggs if they work with the egg we develop. See all my different mails about this topic! Yes, please do. It's up to people making changes to use some judgement. I mentioned in that thread that when I make changes to "core" components, I often do test against the old trunk tree. Despite all of your complaints about the need to do this, you didn't. How is the recommended process to solve this? Some sort of unittest to make sure the deferred impoirt work? Is there an example of this somewhere? I'm proposing to test against a set of possible breaking stuff. This means we need a kind of zope3 trunk egg which our test will deoend on. As I mentioned in the thread you want us to pay attention to, this isn't necessary. In fact, I doubt it would be useful. I think we need a Zope 3 application buildout that builds the traditional Zope 3 app. You can then introduce a develop egg for the package you are changing there. In the mean time, all you need is a trunk checkout and, possibly, to adjust an external. (I don't remember how the externals are set up there.) See the mails form Stpehan Richter about that. Jim also agrees on that but is thinking this should be optional as far as I understand the mails between Stephan and Jim. We defently lost the overall tests we had in the trunk setup. Most people aren't changing these components. Nevertheless, we still have the old tree available for testing. We didn't lose anything. And this is a very bad idea. If we don't recommend to run all tests again form a single egg refactoring, we will see more errors like this. Don't you think it's a little hypocritical bemoaning that we're not doing this when you don't do it yourself? ... I personaly think, less test -- more errors. So test! What's stopping you? The old tree is still available! If someone wants to make this better, a working Zope 3 application buildout would help a lot. I doubt it would be that hard to finish at this point. 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] major packaging reorganization happening in 3.4 releases?
On Oct 2, 2007, at 5:25 AM, Martijn Faassen wrote: Hi there, Besides causing us a lot of problems here at the Grok sprint, I also wonder why in the world are we doing major packaging reorganizations and releasing them as minor 3.4.x releases? You'd think such a reorganization would warrant a 3.5 release! Agreed. Someone needs to sloow down. "Speed kills." deserves to be added to the Zen of Python. (Actually, ZoP does have a variation of that.) 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: New package zc.configure provides an exclude directive for excluding zcml files
On Oct 2, 2007, at 3:29 AM, Martijn Faassen wrote: Jim Fulton wrote: [snip] Maybe grok was already trimmed down. In my case, I basically eliminated all ZMI support (since I didn't need it). I got about 40%, Grok is trimmed down in the sense that it doesn't depend on all Zope 3 packages, though due to the interesting dependency structure it still relies on about 100 eggs. We didn't do any trimming down of ZMI support. Note that it wasn't my goal to trim the number of eggs I got, although trimming that, or, in theory, using zipped eggs would speed startup as well. I'm using the zope.app.zcmlfiles egg as my base. Would it be possible to get a list of exclude statements that you use to eliminate ZMI support in your project? I imagine our list is far from complete. Here is the zcml file I'm including rather than incliding zope.app.zcmlfiles/configure.zcml: http://namespaces.zope.org/zope"; xmlns:i18n="http://namespaces.zope.org/i18n"; i18n_domain="zope" package="zope.app.zcmlfiles" > file="session.zcml" /> file="ftpplugins.zcml" /> file="httpplugins.zcml" /> file="groupfolder.zcml" /> file="password.zcml" /> file="principalfolder.zcml" /> Note that this was made by just copying the configure.zcml from zope.app.zcmlfiles and commenting out some things and adding excludes. I basically kept commenting things or excluding things until my tests failed. :) I could probably go a little further if I worked a lot harder, so of course, I stopped. :) I'll also probably have to add some things back later when I pay attention to i18n. (This app uses extjs for it's UI and I haven't figured out how I'm going to approach i18n for that. extjs rocks btw.) 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] zope.app.securitypolicy deferred imports errors.
On 10/2/07, Roger Ineichen <[EMAIL PROTECTED]> wrote: > In other words; Right now we only test if a egg works > within their dependency. But we don't test other eggs > if they work with the egg we develop. Well, first of all we need tests in the modules that the deferred import works. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: AW: Re: AW: Are pagelets content providers?
Roger Ineichen wrote: > Yes you are right, that was the reason I didn't define the __init__ method > in the interface. But I still think a IPagelet isn't a IContentProvider by > default. Of corse another class can be defined as IContentProvider and > IPagelet. Such a class whould then provide a different __init__ method > then the pagelet does right now. See my other response I wrote before I read this message of yours. > Should we implement a z3c.form/z3c.pagelet package? There we could support > z3c.form base classes built up on pagelets. > > Probably called z3c.formpagelet which contains IPageletForm, > IPageletAddForm etc. This would solve my use case but sounds like a lot of architecture, to be honest. I think this is exactly what I hoped to avoid by pinning the internal communication between pagelets and pagelet renderers down to talking IContentProvider and thereby allowing pagelets to be used as content providers from everywhere. See the "dead chicken" remark in my first reply to you. -- Thomas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: AW: Are pagelets content providers?
Roger Ineichen wrote: > Probably we should say; > "Pagelets are views which support the publisher __call__ attribute and > provide the update/render pattern." True. > You are wrong here. A IContentProvider doesn't define content. A > IContentProvider provides content. That's different. I see difference between creating content and providing it by a content provider interface, but since the content created by some code must somehow be passed to whatever then provides IContentProvider if it isn't the same object anyway, that "some code" might as well provide IContentProvider itself. In the case of pagelets the implementation does that already anyway. > I a component defines content it provides the IPresentation interface > which is the case for IPagelet. No, it isn't. The ancestry of IPagelet doesn't include anything named IPresentation or similar. > A IContentProvider knows only how to get content for another component. > Again, it's a delegation pattern. So what's the business with all that delegation? Why must the source of content be distinct from the content provider? It certainly isn't that way for viewlets. What more is there to the delegation than in the case of pagelets, the need to access the same pagelet instance for creating content that has already been instantiated as the view? > You are saying, that we have IContentProvider providing content and > defining content. Define content is the part of the IPresentation > interface. Which, in turn, does appear in the ancestry of IContentProvider. Provision of IPresentation doesn't seem to be a reason for pagelets not to be content providers. > Probably I don't understand this correct. Are you thinking about a > IContentProvider which collects more then one pagelet? Exactly. Or rather, more than one content provider, more than one of which might just happen to be pagelets if someone thought it might make sense to also use them that way directly. > Probably I don't > see your idea. Can you descibe it what do you mean with "as long as ... > page of its own" and "pagelet as content provider". Well, z3c.form is about creating an HTML form from a schema. Such a form appears somewhere on a page, which might be the place the pagelet content ought to go. If this is all you want, the implementation of a form as a pagelet is fine. However, you might want something more complex to fill that place, something that contains a form among other elements. Now you're in a pinch: you want to use z3c.form for its functionality of assembling an HTML form from a schema, but what you get is a pagelet that, by being denied recognition as a content provider, shouldn't be used as a part of what makes up the pagelet content. > I don't understand how a pagelet can get called as a content provider. > The adaption doesn't work because they support different __init__ method > signatures. Unless I'm mistaken, this has to do with the way view classes are created by the ZCML viewlet directive - which is how I've used it so far. > Did you recognize that the __init__ are different. > > A IContentProvider defines: > > def __init__(self, context, request, view) An interface does not define the constructor signature of classes that might implement it. Interfaces are about communicating with instances of classes implementing them, not about creating those instances. > I guess there is nothing wrong with your idea, you can allways mix > IContentProvider and IPagelet in a new interface. But the existing > implementation of IPagelet is not a IContentProvider out of the box. I think that it would be better to define pagelets to be content providers so as to know what to deal with than to have to repeat that IContentProvider thing for every extension interface and implementation. It's not as if IContentProvider was all that specific anyway. Having to add it explicitly again and again sounds like a dead chicken. > A IPagelet called by the IContentProvider TALES expression whould have > to support __init__(self, context, request, view) which isn't the case > in the Pagelet implementation. This isn't the interface's business but sounds more like a factory function that instantiates the pagelet without passing the view to the constructor and adds it as the __parent__ attribute afterwards. > Does this make sense for you? I understand the problems that have to be solved, but as long as you're talking about __init__ being specified in interfaces, it doesn't make sense to me. > what do you think about to remove the formlib implementation from the > z3c.pagelet package? I think it would make things cleaner and make it easier to see what belongs where. Plus there's possibly not much need to wrap zope.formlib in pagelets given the existence of z3c.form. Removing the stuff sounds like applying "there ought to be only one way to do it", so I'm all for it. -- Thomas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope
AW: AW: [Zope3-dev] Re: AW: Are pagelets content providers?
Hi Jacob, Thomas > Betreff: Re: AW: [Zope3-dev] Re: AW: Are pagelets content providers? > > Hi Roger, > > I didn't follow this discussion closely but thought this > needed a comment. > > Roger Ineichen wrote: > > [snip lots of context...] > > Did you recognize that the __init__ are different. > > > > A IContentProvider defines: > > > > def __init__(self, context, request, view) > > self.context = context > > self.request = request > > self.view = view > > > > and a IPagelet defines: > > > > def __init__(self, context, request): > > self.context = context > > self.request = request > > > > Probably we should describe this in the interface too. > > This whould manifest the difference of content provider > which provide > > content and pagelets whcih defines content in a better way. > > > It would make sense to have the 'view' attribute a part of > the IContentProvider interface, and *that* might make them > different. The constructor signature is all about the class > instead of the instance and should therefore *not* be part of > the interface. > > It is perfectly reasonable to have a number of different > (multi-)adapters with different signatures that adapt to the > same interface. > > Hope this makes sense. I'll go back to lurking now. Yes you are right, that was the reason I didn't define the __init__ method in the interface. But I still think a IPagelet isn't a IContentProvider by default. Of corse another class can be defined as IContentProvider and IPagelet. Such a class whould then provide a different __init__ method then the pagelet does right now. Thomas; Should we implement a z3c.form/z3c.pagelet package? There we could support z3c.form base classes built up on pagelets. Probably called z3c.formpagelet which contains IPageletForm, IPageletAddForm etc. Regards Roger Ineichen > Regards > > Jacob > > -- > Jacob Holm > CTO > Improva ApS > > ___ > 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
Re: AW: [Zope3-dev] Re: AW: Are pagelets content providers?
Hi Roger, I didn't follow this discussion closely but thought this needed a comment. Roger Ineichen wrote: [snip lots of context...] Did you recognize that the __init__ are different. A IContentProvider defines: def __init__(self, context, request, view) self.context = context self.request = request self.view = view and a IPagelet defines: def __init__(self, context, request): self.context = context self.request = request Probably we should describe this in the interface too. This whould manifest the difference of content provider which provide content and pagelets whcih defines content in a better way. It would make sense to have the 'view' attribute a part of the IContentProvider interface, and *that* might make them different. The constructor signature is all about the class instead of the instance and should therefore *not* be part of the interface. It is perfectly reasonable to have a number of different (multi-)adapters with different signatures that adapt to the same interface. Hope this makes sense. I'll go back to lurking now. Regards Jacob -- Jacob Holm CTO Improva ApS ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] zope.app.securitypolicy deferred imports errors.
Hi Lennart > Betreff: [Zope3-dev] zope.app.securitypolicy deferred imports errors. > > Roger Inechens split of zope.app.securitypolicy into > zope.securitypolicy cause loads of problems, because many of > the deferred imports were incorrect. I saw Stefan Richter > fixed some, and I have fixed some more. Yes you are right > First somebody that can make releases (which may or may not > include me, I honestly don't know who can make releases of > eggs) needs to make a new one. But we also need to avoid this > stuff in the future. Yes, we always have to avoid errors, but sometimes it happens. And since we dont test against the trunk, we don't see this kind of errors anymore. This means we test against custom projects. I didn't fully recognize this and was trusting the tests. But I was wrong. We don't have tests for this anymore. We probably didn't have test for my error at all. In other words; Right now we only test if a egg works within their dependency. But we don't test other eggs if they work with the egg we develop. See all my different mails about this topic! > How is the recommended process to solve this? Some sort of > unittest to make sure the deferred impoirt work? Is there an > example of this somewhere? I'm proposing to test against a set of possible breaking stuff. This means we need a kind of zope3 trunk egg which our test will deoend on. See the mails form Stpehan Richter about that. Jim also agrees on that but is thinking this should be optional as far as I understand the mails between Stephan and Jim. We defently lost the overall tests we had in the trunk setup. And this is a very bad idea. If we don't recommend to run all tests again form a single egg refactoring, we will see more errors like this. Some of us are thinking about to automate this tests with buildbot. But this tests will only test released packages which is also bad. I think the only way to automate such tests can be supported by a staging server. I personaly think, less test -- more errors. Even if we try hard to avoid errors during development. Regards Roger Ineichen > -- > Lennart Regebro: Zope and Plone consulting. > http://www.colliberty.com/ > +33 661 58 14 64 > ___ > 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] Re: AW: Are pagelets content providers?
Hi Thomas > Betreff: [Zope3-dev] Re: AW: Are pagelets content providers? > > Roger Ineichen wrote: > > > I was carfully skip some additional method decalration because I > > didn't know if we gona use IPagelets without render and update in > > other implementations. > > The z3c.pagelet README.txt says that "Pagelets are views > which can be called and support the update and render > pattern." So either this refers to the particular > implementation only, in which case I'd say an independent > definition of the concept of pagelets is missing, or > otherwise it doesn't leave much room for implementations > without update and render methods. Probably we should say; "Pagelets are views which support the publisher __call__ attribute and provide the update/render pattern." > > I disagree, the IPagelet is not a IContentProvider. The > pagelet is the > > component which defines the content and the renderer is the content > > provider. It's a delegation pattern. > > > > I explicit didn't implement IContentProvider in IPagelet because a > > pagelet has to conceptual functionality of a page and not > of a content > > provider or viewlet thing. > > So the pagelet is really two things: a specific > implementation of a browser page, and a component which > defines content. Both should reflect in its interface, and > why should something which defines content and follows the > update/render pattern not formally be declared a content > provider? Calling it something else with the same methods > serves only to keep around an interface twice, by different names. You are wrong here. A IContentProvider doesn't define content. A IContentProvider provides content. That's different. I a component defines content it provides the IPresentation interface which is the case for IPagelet. A IContentProvider knows only how to get content for another component. Again, it's a delegation pattern. > AFAICS, there's nothing wrong with two content providers > taking part in delivering the pagelet's content: one that > originally creates the content behind the scenes, and one > that is called from the layout template and delegates content > creation to the former. You don't have to prohibit a pagelet > to be called a content provider in order not to call it from > the template directly. The issue might just be about > interfaces describing how an object can be used instead of > what code is supposed to use it. You are saying, that we have IContentProvider providing content and defining content. Define content is the part of the IPresentation interface. > OTOH, there's real value in pagelets being content providers: > library or application developers wouldn't have to decide up > front whether their content providing component is to be used > for primary or supplementary page content by deciding whether > to implement it as a pagelet or a content provider; it could > be both without adding any dead chicken abstractions. > > A real-world use case is z3c.form forms: they are implemented > as pagelets which is fine as long as each form makes up a > page of its own. However, we'd like to combine forms with > other stuff, such as a search form with a result list. This > is possible by using a form (a pagelet) as a content > provider, but that feels like a hack as long as it isn't > backed by formal interfaces. Probably I don't understand this correct. Are you thinking about a IContentProvider which collects more then one pagelet? Probably I don't see your idea. Can you descibe it what do you mean with "as long as ... page of its own" and "pagelet as content provider". I don't understand how a pagelet can get called as a content provider. The adaption doesn't work because they support different __init__ method signatures. > > The interface IPagelet(IBrowserPage) should reflect the > page replacement. > > > > The IPageletRenderer(IContentProvider) should describe the > pattern how > > the pagelet content get accessed. > > > > Dou you see my idea behind this declarations? > > I do, but I can't follow the conclusion that pagelets should > not at the same time be declared content providers, which > they de facto are. > > > What do you think, should we add render/update to the > IPagelet which > > is not defined in IBrowserPage? > > > > Or should we add a IRenderUpdate interface in zope.? which > we can use > > in zope.formlib, z3c.form, z3c.pagelet and probably many > more interfaces? > > Having thought some more about it since asking it as a > question yesterday, I now definitely think that IPagelet > should extend both IBrowserPage and IContentProvider. I can't > see any value in a new IRenderUpdate interface since the > distinction from IContentProvider would be very academic IMO. Did you recognize that the __init__ are different. A IContentProvider defines: def __init__(self, context, request, view) self.context = context self.request = request self.v
[Zope3-dev] Re: major packaging reorganization happening in 3.4 releases?
Martijn Faassen wrote: Besides causing us a lot of problems here at the Grok sprint, I also wonder why in the world are we doing major packaging reorganizations and releasing them as minor 3.4.x releases? You'd think such a reorganization would warrant a 3.5 release! What doesn't help release managers is that the package reorganization wasn't discussed in CHANGES.txt. This means that a release manager can release what *they* think is a minor bugfix release but actually release pretty disruptive changes. 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] major packaging reorganization happening in 3.4 releases?
Hi there, Besides causing us a lot of problems here at the Grok sprint, I also wonder why in the world are we doing major packaging reorganizations and releasing them as minor 3.4.x releases? You'd think such a reorganization would warrant a 3.5 release! 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] zope.app.securitypolicy deferred imports errors.
Roger Inechens split of zope.app.securitypolicy into zope.securitypolicy cause loads of problems, because many of the deferred imports were incorrect. I saw Stefan Richter fixed some, and I have fixed some more. First somebody that can make releases (which may or may not include me, I honestly don't know who can make releases of eggs) needs to make a new one. But we also need to avoid this stuff in the future. How is the recommended process to solve this? Some sort of unittest to make sure the deferred impoirt work? Is there an example of this somewhere? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: New package zc.configure provides an exclude directive for excluding zcml files
Jim Fulton wrote: [snip] Maybe grok was already trimmed down. In my case, I basically eliminated all ZMI support (since I didn't need it). I got about 40%, Grok is trimmed down in the sense that it doesn't depend on all Zope 3 packages, though due to the interesting dependency structure it still relies on about 100 eggs. We didn't do any trimming down of ZMI support. Would it be possible to get a list of exclude statements that you use to eliminate ZMI support in your project? I imagine our list is far from complete. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
