[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Just note that I'm explicitly not addressing automation as a use case for > custom ZCML directives. I believe automation is best done in Python. If you're > trying to invent a new ZCML directive that does something else to an > adapter/view/utility before registering it (e.g. putting an interface on it, > adding attributes, wrapping it in a factory etc.), then that should be done in > Python. zope.formlib is a good example of how browser:page is enough for > registering a form as it isn't ZCML's concern *what* kind of page we're > registering. All that is in Python. I'll aggree to an extent: where this pactice breaks down is when the "argumentes" to the automation need to be supplied as configuration. At that point, a wrapper argument which allows the user to specify those values without writing / modifying PYthon can be a win. In the case of Shane's "webroot" proposal, for instance, the filesystem path to the root would be best specified as an attribute to a custom directive, even if the directive did nothing more than configure a single global utility. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8cKj+gerLs4ltQ4RAvo3AKCs0XzL07Yo6TYUGjtR9TwVHsWkSQCgvSul z/pSuIU/iBLm3x3ad1IR2G4= =fyuR -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: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Martijn Faassen wrote: >> I suspect quite >> a few of the directives that can go away are in the 'small' namespaces, >> such as mail. We may also want to move some directives to other >> namespaces. If all directives disappear from a namespace, so can the >> namespace. The potential for win can be much larger while the potential >> for breakage is much smaller, as we can do this step by step. > > I agree. As we do that, we should also try to figure out when and how we > decide > what goes into its own namespace and what doesn't. Currently ZCML namespaces > are used to: > > * Differentiate between different view types (generic vs. browser vs. xmlrpc) > > * Mark the domain of a certain registration (i18n, mail, rdb, help) > > * Associate directives with a certain, perhaps optional package (apidoc, other > 3rd party packages) > > Why does apidoc have its own namespace and, say, zope.app.securitypolicy > doesn't? Or why did zope.viewlet not put its directives into the 'viewlet' > namespace but into the 'browser' namespace? All that seems arbitrary to me. > Just as the fact that I'm "supposed" to put my frobnatz directive into the > plone namespace even if a frobnatz is actually a browser thing. I think the clue here is to put your directives into a namespace whose UIR you "control": in the case of 3rd-party packages managed outside of the 'zope' package, I think that this means somewhere other thatn 'namespaces.zope.org' (the prefix, of course, is rebindable on a per file basis). I think 'zc.resourcelibrary' does this wrong, injecting its 'resourceLibrary' directive into the main 'zope' namespace; perhaps 'http://namespaces.zope.org/zc' would be better. >> I really think that the discussion on namespaces is so common not >> because it's so important, but because it's an easy thing to comment on >> and talk about. People are less likely to have huge discussions about >> larger but harder to understand issues. > > Perhaps. But it also seems like they're talking about it because it bugs them > a > lot. Tres seems to think that we shouldn't worry about those "trolls". I'm > inclined to think that if people have issues with ZCML and welcome > simplifications, we should consider coming up with some. So far I'm the only > one who has made constructive suggestions for doing so beyond Jim's adapts() > hook (I won't count suggestions that seek to replace ZCML with ZConfig, YAML, > etc.). I don't think objecttions based on "why do I have to type the namespace declrartion?" are valid: they get trumped by "explicit is better than implicit," if nothing else. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8cgC+gerLs4ltQ4RAp3aAJ9BM3CDM5pNuJtEUu09MEYaRSTwLgCgseOh EnR5MUdGdPdqGwMSXO1PqVs= =Ui3c -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: RFC: Reducing the amount of ZCML directives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On 2/14/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > >> > component=".alias.sydneyFactory" >> name="alias.SydneyBristow" >> /> >> >>The naming of the component already gives it away as a factory. To me that's >>enough naming. > > > I think I agree. This to me makes sense. If it were nameless (are > there nameless utilities) you could then get off with just component=".alias.sydneyFactory" /> which is then the on/off switch we > mentioned earlier. And an adapter should be registered the same way > and what it adapts > between should be a part of the python-code with an adapts(ISomething) > declaration, just like implements(ISomethingelse), which I think you > suggested in your "ZCML does doo much" blog, right? The use case here is for registering "components" (in particular, factories) which don't / can't have the CA metadata hard-wired into them: e.g., they are functions, not objects, or they are in "read-only" library code. It is also conceivable that the metadata they declare is overharsh, and that the component might work well with an "equiavlent" interface to the one it was written for. In this case, ideally one would update the software with a more generic interface; but allowing the configuration file to override the metadata is a "workaround." Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8clC+gerLs4ltQ4RAqj+AKCuEuRhN9OONBq05FaLGTiW9AJqtACguXqE ijXt6KrV346wnho6TIKd8m8= =nYS9 -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: Zope 3 web root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: > Jeff Shell wrote: > >> I agree that better integration with external data should be a >> priority for Zope. But what does that mean? In theory, if something's >> a Python object it should work with Zope 3 with relative ease... If >> that's not the case, perhaps we need to look at how much work is >> required to take some random Python object that may be created by some >> random data access library and get it into a Zope 3 published web >> page. If it kicks and screams and resists security and interfaces, or >> what not, maybe we need to take a look at all of that. > > > Let me focus the discussion: I think it's nearly always a bad idea for > anyone, newbie or expert, to put a template or script in ZODB. Do we > have any agreement on that point? I wish we did. I enjoy ZODB for many > purposes, but not for storing templates and scripts. I have a real client application where the templates themselves *are* the content being managed: they are *not* software. They *must* be stored in the ZODB. You could think of these things as "active content components," or somthing, and they are not logically the same thing as "stock" templates used for software, but they do include ZPT. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9Jni+gerLs4ltQ4RAmrjAKCiwoNHJd8ZTKqnJ+8FemITlPuQtwCfZ3nC QxO8Etxh2cyrUIMb7tcvzE4= =KLiU -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: [Zope3-dev] Re: Two visions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Max M wrote: > >> Jim Fulton wrote: >> >>> 2) In an alternate vision, Zope 2 evolves to Zope 5. >> >> >> >> Zope 2 is complicated! It has too many layers of everything. >> >> The reason for Zope 3 is to make it simpler for developers. >> >> Therefore I believe that any succesfull strategy would require Zope 3 >> to be usable completely without all the Zope 2 layers. >> >> If Zope 3 becomes just another layer on top of Zope 2 -> CMF -> Plone >> it will not reduce complexity, as any developer would still need to >> learn the entire stack. >> >> Wherever practical, Zope 2 technologies should be rewritten to Zope 3 >> technologies to remove layers from the stack. > > > I think these are good points. > > Five runs the risk of being yet another layer on a stack like Plone, but > Five also gives the chance of us stripping off these layers and > replacing it with something cleaner, and at the same time Five is giving > an impulse to Zope 3 development as things slowly get ported to Zope 3 > or written in a Zope 3 style. > > The Five project has the right attitude to deal with such integration > issues. We have been quite successful: In Zope 2.9 it's possible to > build modern Zope 3-style apps, using formlib and sqlos and so on (we've > done it). > > In this vision, the Zope 3 project should stay where it is and push > things forward. That doesn't mean Five should be ignored by Zope 3 > developers, but it should be compartmentalized in people's minds. Zope 3 > does innovation, Five does integration, and then the big codebases can > move forward using both. I think the other major point is the "door #2" proposal takes pressure off of Zope3: under that regime, Zope3 does not need to grow all the features present in Zope2, which door #1 *does* imply. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEBHBA+gerLs4ltQ4RAs22AJ44rNQIZB9HCt1S6fp7s36Hq68MNgCgv37w PHiyspa7XahkllCJmueEU5w= =ZyJQ -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: Notice: zope.interface is now a separate project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: > On Sat, Mar 04, 2006 at 12:38:38AM +0100, Thomas Lotze wrote: > >>What was the reason for choosing these and not choosing others? > > > Minimal dependencies. > We thought we should start with easier packages. Right. The selected packages tend to be dependencies for the others, as well. The eventual plan is to have *all* the non-app Python packages distributable as eggs, as well as moving out large chunks of stuff currently under zope.app. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFECPgC+gerLs4ltQ4RAvajAJ479R8ytjILUGWdSOcQnQ+20s2OuwCgsycR dgzEfQzDKugojSjbfZxC3Sg= =mfxA -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: traceback when running tests for zope.app.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 j.kartnaller wrote: > Benji York wrote: > >> jürgen Kartnaller wrote: >> >>> Benji York wrote: >>> >>>> I emailed the committer Friday about this, but no fix has been >>>> forthcoming, so I reverted the offending revisions. Hopefully a >>>> revised >>>> version can be reapplied soon. >>> >>> >>> Still the same problem after your revert ! >> >> >> The tests pass on my box and on all the buildbot machines (and they >> didn't before). Perhaps you're seeing a different problem. I didn't >> compare the tracebacks to be sure. > > > The traceback only occurs when running the test for zope.app.component : > > python test.py --package=zope.app.component > > A full test runs without problems. A trunk checkout fails for me with the same traceback when run with that command line. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEDFP2+gerLs4ltQ4RAkyOAJ9kIr6yWO7iK9sAkDOA8LxOTmHhdACfV+FU bt9FlEcGL/TCSBWQYzXT3kU= =w0Hz -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: what is ZCML?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: > On 3/13/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: > >>Martijn Faassen wrote at 2006-3-13 17:15 +0100: >> >>>... >>>A newer interpretation of ZCML is: >>> >>>""" >>>ZCML is a configuration language that configures a number of basic >>>directives for configuring the component architecture and security: >>>adapters, utilities, security requirements, and little else. Everything >>>else should be done in Python code, as configuration in Python code is >>>more flexible and packages can form a more self-contained whole. ZCML >>>should reflect the underlying universality of the component architecture. >>> >>>If two directives work with, say, adapters underneath, they should >>>really be one directive. ZCML should be simple and minimal so it is easy >>>to grasp. >>> >>>ZCML is not readable standalone. ZCML is simply used to turn on various >>>adapters and such, hooking them into the system, but we do not get a >>>clue what the adapters are doing by just looking at the ZCML - Python >>>code needs to be consulted. >>>""" >>> >>>I believe that this interpretation is the up-and-coming interpretation >>>of ZCML. >> >>I hope not... >> >>Note, that configuration files should be understand and >>adaptable by administrators. Therefore, they should be readable >>and understandable -- without an understanding of the implementation >>(but with reading of the component documentation). > > > I think differently. ZCML is primarily for programmers. ZConfig style > configuration is what administrators deal with more, isn't it? Maybe > ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files. > > I don't think of ZCML as administrative configuration. It spells out lots of site policy which must *not* creep back into the "software". > I'd rather have Python files that I can read and understand what's > going on without having to consult ZCML files, directives, > documentation, and so on, just to understand why a certain class whose > code I'm looking at is getting its behavior when I can see no > superclass. I'd like to know that a class I'm looking at is an adapter > and what it provides and what it adapts without having to dig through > a large ZCML file. > > An administrator is not likely to override my 'inplace_editor' view. Really? You have no options which an admin might want to change, either on a site-wide basis or within a single folder? How about choices like whether to accept HTML 4.0 versus XHTML 1.0? What about tag blacklists? > He may want to configure global services (if my application is written > that way) such as RDB connection parameters and mail services. But > beyond that, just loading it up in package-includes or in a specific > file is likely to be the bulk of 'administrative' effort. > > Did administrators go into your ``initialize(context)`` functions in > your Zope 2 Product's __init__.py files and change things? That's what > I view ZCML as being - a better version of that. (Better in only that > configuration and initialization can be executed separately from > Python imports) We need to get beyond the idea that Python is the ideal place to spell everything. It is particularly bad to have to modify the software shipped by the developer in order to change policy, which is where we are going if we continue down this road. Having to accept choices made by a component developer is a barrier to reuse; we won't win brownie points for all our cool components if we make it hard to use a comoponent without accepting either *all* or *none* of its configured policy choices. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFhdD+gerLs4ltQ4RAptSAJ4lvBZ2f7iwodYUP8l9J4j+nqoYcQCgr5qb c4HIIpb1Kkm/KuQ7yMYiGdU= =F/SR -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: Zope Eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan R. Yergler wrote: > During the Zope3 sprint following PyCon, Paul and I, with Jim's > guidance, began work on exploring how Zope can utilize eggs and be > packaged using eggs. Since we're still experimenting with how eggs > will be used, I wrote a script, zpkgegg, which reads the zpkg > configuration information for a package and generates a "standard" > setup.py from which an egg and vanilla sdist can be generated. > > You can find the script in subversion in the projectsupport project. > For a brief overview of how the script is used, see README.txt (in > http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs > generated by zpkgegg do not attempt to distinguish between "runtime", > "testing" or "development" dependencies, so almost all packages will > want zope.testing. README.txt contains a brief example of how to > point easy_install at the appropriate folders so that easy_install can > resolve the dependencies. > > Note that at this point we're still experimenting with how we'll use > eggs, so suggestions, feedback and comments are welcome. I've been playing around a lot, trying to get at least the eggs together to make ZPT usable outside of Zope (one of the original sprint goals). I have a couple of observations: 1. Putting 'setup.cfg' under version control sucks, because the 'develop' framework scribbles on it. I think we should do two things: - Move any "special" settings to a 'setup.cfg.in', and modify the workspace stuff to read that first when creating setup.cfg. - Make 'setup.cfg' a 'svn:ignore' file (at lest on the trunk). 2. Getting the development dependencies installed was harder than it seemed. Some packages (perhaps with help from a stanza in 'setup.cfg') could do that when running 'develop.py'; others needed me to run 'setup.py develop'. Maybe we should just kick off 'setup.py develop' at the end of the 'develop.py' dance? 3. I was hoping to get 'setup.py test' working, but that command in setuptools doesn't honor the command-line arguments for egg handling. 4. We need to begin creatinng "released" versions of the eggs (maybe numbering them according to the Z3 release they point into), and reorganizing the download page a bit (maybe "development" builds need to go on one page, and "release" builds on another). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEF0fm+gerLs4ltQ4RAmrpAJoDoHdjtKphZJPy9tXG5tGjde0+hgCfaFZo tmvntIJnqEyc4tMS3UrLrXI= =G//3 -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: what is ZCML?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Martijn Faassen wrote: > >> Shane Hathaway wrote: >> >>> Jim Fulton wrote: >>> >>>> Shane Hathaway wrote: >>>> >>>>> +1. When I learn a skill, it is at first completely explicit, and >>>>> as the skill becomes predictable and reliable, it gradually becomes >>>>> implicit. If I kept everything explicit, I would hinder myself >>>>> from building higher level skills. >>>>> >>>>> So explicit is better than implicit until a sufficiently tight >>>>> abstraction comes about. Take memory management: yesterday it was >>>>> explicit (malloc/free); today it's mostly implicit (garbage >>>>> collection). Garbage collection is both an abstraction, since >>>>> programmers no longer manage memory directly, and an indirection, >>>>> since programmers now use APIs that call malloc and free. We all >>>>> agree GC is good, so explicit is definitely not always better than >>>>> implicit. >>>> >>>> >>>> >>>> Thanks for explaining "Explicit is better than implicit, >>>> except when it's not." >>> >>> >>> >>> Admittedly, I should have posted that in my blog, not here. :-) >> >> >> >> I appreciated you making it explicit, Shane, even though I already >> knew and fully agree. :) >> >> I sometimes express this principle as "magic is bad unless it's >> perfect magic". Do post it on your blog. > > > Yes, it is a good thing to know, except that it is incomplete and > obscures an important point. Magic always has the downside that it > hides things. Often, as in the case of garbage collection, the benefit > outweighs the cost. Too often though, people introduce magic > (aka abstraction, indirection, automation) when the benefit doesn't > justify the hiding. One should always approach magic with skepticism. > > This is an important design principle. The "explicit is better than > implicit" is a guide, not a rule never to be broken. It's something we > should start with. Does that mean we never provide automation? Of > course not. I wonder if there isn't a sore spot which is driving a lot of the discussion here, but isn't being mentioned: the experiment in form definition (browser:addform / browser:editform). The interesting thing about that experiment is that it *almost* worked, as magic; its failure was not in what it made easier (generating a view from a schema *and* a policy), but in what it made harder (changing the behavior of the generated view). Developers who are the only admins for the sites they deploy are *not* representative of the intended audience for ZCML; they are much more comfortable with "back to Python" as a solution than more traditional admins / integrators would be. "Big" directives, with clearly documented knobs for specifying policies, are likely to appeal more to folks sho are *not* inclined to write Python. The fact that such developer-admins are the primary users of ZCML so far is due to the small size of the Zope3 market to date. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGD5f+gerLs4ltQ4RAnCjAKDb/6AM4phxLZhHnSPH554Ysv8CIwCfRIUo 8+DrkkvhQFQDB8WGCSC70j4= =X/7J -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: Zope Eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Tres Seaver wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Nathan R. Yergler wrote: >> >>> During the Zope3 sprint following PyCon, Paul and I, with Jim's >>> guidance, began work on exploring how Zope can utilize eggs and be >>> packaged using eggs. Since we're still experimenting with how eggs >>> will be used, I wrote a script, zpkgegg, which reads the zpkg >>> configuration information for a package and generates a "standard" >>> setup.py from which an egg and vanilla sdist can be generated. >>> >>> You can find the script in subversion in the projectsupport project. >>> For a brief overview of how the script is used, see README.txt (in >>> http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs >>> generated by zpkgegg do not attempt to distinguish between "runtime", >>> "testing" or "development" dependencies, so almost all packages will >>> want zope.testing. README.txt contains a brief example of how to >>> point easy_install at the appropriate folders so that easy_install can >>> resolve the dependencies. >>> >>> Note that at this point we're still experimenting with how we'll use >>> eggs, so suggestions, feedback and comments are welcome. >> >> >> >> I've been playing around a lot, trying to get at least the eggs together >> to make ZPT usable outside of Zope (one of the original sprint goals). >> I have a couple of observations: >> >> 1. Putting 'setup.cfg' under version control sucks, because the >> 'develop' framework scribbles on it. I think we should do two things: >> >> - Move any "special" settings to a 'setup.cfg.in', and modify the >> workspace stuff to read that first when creating setup.cfg. >> >> - Make 'setup.cfg' a 'svn:ignore' file (at lest on the trunk). > > > Agreed. IMO, we should either not scrible on setuop.cfg or not check it in. > I vote for not scribbling on it. I'd rather not check it in, myself. Even if the 'develop.py' helper doesn't scribble, it is a natural place for the developer to scribble. Generating it when needed, and ignoring it for version control, seems healthier to me. Perhaps we should use a different strategy for "released" packages than "trunk" ones? >> 2. Getting the development dependencies installed was harder than >>it seemed. Some packages (perhaps with help from a stanza in >>'setup.cfg') could do that when running 'develop.py'; others >>needed me to run 'setup.py develop'. Maybe we should just kick >>off 'setup.py develop' at the end of the 'develop.py' dance? > > > I suspect these are just lingering bugs. > > One thing I noticed, when I tried a few days ago was that zope.testing > had a bogus dependency that made it's installation fail. > > ... > >> 4. We need to begin creatinng "released" versions of the eggs (maybe >>numbering them according to the Z3 release they point into), and >>reorganizing the download page a bit (maybe "development" builds >>need to go on one page, and "release" builds on another). > > > Why do you say this? I agree that we need this eventually, but it > feels a bit early to me. I think that getting the eggs usable outside of Zope is a goal, and one which makes getting the packages "released" more urgent than simply changing Zope to use them (which won't happen until November at the earliest). Many of the packages are actually very stable, and could easily be released now, assuming some elbow grease is applied. > Also, I expect and hope that many packages > will have release cycles independent of Zope. That will require that they get maintainers who actively manage them. One sign of such a package is that it has its own CHANGES.txt file, and that its bugfix / feature entries end up there, rather than in Zope's changelog. For the time being, I'll be content with packages which merely point into the release tag area of Zope. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGEBg+gerLs4ltQ4RArzYAKDNkq4C4JTPaloz3qu/C1p8s3A0BwCgw9f/ r+ZGtDI1V5Zv9KkjcSOY5+0= =FZXB -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: Internal architecture or ZopeX3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhold Strobl wrote: > Further I'd like to know, what happens to ZPT at runtime. Are they compiled > into > Python modules? No, they are compiled into bytecodes exceuted by the TAL interpreter, which is invoked when the template is rendered. Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGXYZ+gerLs4ltQ4RAn+7AJ93hl5bvHkgwi4IZdzZQGoemuqMvQCfXsDF xj4Cw0mt6zN+oQQKCbQCEEA= =QEM0 -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: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > * sources and terms are nice, but we should at least provide some basic > sources and register some basic terms for them; that bit is completely > missing in Zope 3 right now. People should be able to at make a simple > drop-down widget happen without having to figure out how to tie all > these components together - they should just import and use the right > source, perhaps import, use, and register the right term, and there they > go. Hmm, another case where high-level ZCML support would be useful: defining simple terms for a vocabulary. Why should somebody who wants to tweak a vocabulary have to edit software? E.g.: Plato Aristotle Immanuel Kant Of course, we could also keep the vocabularies in another data file, and merely have the high-level directive "source" it: Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGZRq+gerLs4ltQ4RAqfjAKCVsLoGMDkvqbZVu7r+lPQzqvu3zwCeKYbS 7TZXr/3VwH64Z/w9jbH20sY= =ZUki -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: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: > On Thu, Mar 16, 2006 at 11:38:02AM -0500, Tres Seaver wrote: > >> > > > eh? > > http://www.google.com/search?hl=en&lr=&q=ktupema+necro+halogo&btnG=Search > > "Your search - ktupema necro halogo - did not match any documents. " It is pseudo-Greek from the roots for "beating dead horse". Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGZ0k+gerLs4ltQ4RAtVZAKDacf6/4HCAOnZdLMWZavElzXtiKwCdEJqB xFnW72g4IFLA5AGrNZLSI8I= =UQeT -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: [Zope3-dev] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: > On 3/16/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > >> >> >>Hmm, another case where high-level ZCML support would be useful: >>defining simple terms for a vocabulary. Why should somebody who wants >>to tweak a vocabulary have to edit software? E.g.: >> >> >> Plato >> Aristotle >> Immanuel Kant >> >> >>Of course, we could also keep the vocabularies in another data file, and >>merely have the high-level directive "source" it: >> >> >name="philosophers" >>file="philosophers.csv" >>/> >> >> > > If - and only if - and really really really really really only if - > you mean to do this, fix the HELL up the vocabulary registration > stuff. That's where most of my time got lost when I had that debugging > session the other week that pissed me off to no end about ZCML. I have > no idea how I fixed my situation either. > > By the way, isn't it pretty easy to provide straight up values anyways > for those quick drop-down situations? You're missing the point -- the vocabulary is *not* software, and Python is *completely* the wrong place to define it: it is *pure* policy. THe fact that you are administering all the sites you build blinds you to this fact. My examples move the definition of the vocabulary out into integrator / administratof land, which is where they belong. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGuIB+gerLs4ltQ4RAoBsAJ4mLLGRq1W9rxUtNtcE7KiqnjMBHwCgiJ0z atW0SkVUOxpwn+YAMet6lYM= =ak6r -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: [Zope3-dev] Re: Zope Eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan R. Yergler wrote: >>So right now we scribble the development dependencies as well as path >>(lib, script, etc) information into setup.cfg. The develop.py script >>reads the dependency information and attempts to install them into the >>specified lib directories. So it seems to make sense to put things >>like egg parameters, etc (settings independent of user workspace >>location) into setup.cfg.in, and then have develop.py populate a >>setup.cfg at runtime. I think we really do want a setup.cfg that >>isn't under version control -- storing the path information there >>makes the easy_install commands somewhat less verbose as you don't >>have to specify the script and lib locations each time you run. > > > I just committed changes to develop.py that make it examine > setup.cfg.in if setup.cfg doesn't exist. So setup.cfg.in can contain > any project-specific egg settings and the development time > dependencies, and develop.py will use that as a template for > setup.cfg. See the zope.interface project for an example of using > setup.cfg.in. README.txt in projectsupport has also been updated with > some new details of the develop.py process. Great! I just fixed the other eggification packages I had checked out accordingly, including adding setup.cfg to the svn:ignore list. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHie9+gerLs4ltQ4RAo1NAKC4ksh6q0Mu9daWZv7KkQLB0amstgCgqXgp YCuug6tS1gpFb/1jAm/7wwU= =8lx4 -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: Reducing the Amount of ZCML Directives ready for review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Dominik Huber wrote: > >>I really appreciate your effort in all other cases, but in this case I >>think its not a simplification. > > > At least in case of class/implements it is. I'm merging two directives, > class/implements and five:implements into one. > > The case of class/factory is arguable, I admit. However, there I'm just > following the rule of a) defining things in Python and registering them in > ZCML and b) use more basic ZCML directives, less special ones. That "rule" is somewhat debatable (the debate seems ongoing). I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your "simpler / cleaner" thing. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHrCD+gerLs4ltQ4RAnb7AJ9NyTYi9roHh6IrcyoxqbEeNpuBRgCeLhm3 f6Abhf0JvAOYKZ645Ev7tCQ= =fvkA -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: httpgz in zope.conf?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Washington wrote:
> I announced release of httpgz, http://zif.hill-street.net/httpgz on
> Zope3-Users this past weekend.
>
> It does very nice things to bandwidth. One particular page (tabular and
> very repetitious) went from around 400K to 25K for the client.
> MochiKit.js went from 94254 bytes to 24854 bytes. This makes web pages
> seem much faster, particularly on slower connections.
>
> I am wondering what the best mechanism for turning this on and off would
> be. I suppose it is simple enough to insert and remove the
> httpgz-configure.zcml file in etc/package-includes, but is there a place
> for third-party hooks in zope.conf? Or would that be a bad idea?
There is a mechanism for registering third party schemas in ZConfig.
Zope2 leverages this support, declaring an abstract section type
(''), which allows products to register custom section
types (they can also just add simple key value pairs). The SVN checkins
which enabled this:
$ svndiff -r 39634:39652 \
svn+ssh://svn.zope.org/repos/main/Zope/branches/2.9
Products define custom section types in a 'component.xml', which must
then be imported into the zope.conf (via '%import') before a section of
that type may be used.
Zope3 could add a similar abstract section type to its top-level schema,
for use by third-party extensions. Such a change would *not* require
settling the config-file-format debate.
Tres.
- --
=======
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEHsIA+gerLs4ltQ4RAi3jAKCGCGQjISAsIKgvI9QiyyIHRN2FUQCeM+cZ
wgVKeFv3uwpAF47PYW4D/z8=
=B4lJ
-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: [Zope3-dev] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: > On 3/17/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > >>Jeff Shell wrote: >> >>>By the way, isn't it pretty easy to provide straight up values anyways >>>for those quick drop-down situations? >> >> >> >>You're missing the point -- the vocabulary is *not* software, and Python >>is *completely* the wrong place to define it: it is *pure* policy. THe >>fact that you are administering all the sites you build blinds you to >>this fact. >> >>My examples move the definition of the vocabulary out into integrator / >>administrator land, which is where they belong. > > > No. I think they are software. Or can be as much software as anything > else. Sometimes I don't care what the values I get for a Choice field > are. Sometimes I care very very very much. With the interfaces, > vocabularies can come from a lot of sources. Personally, if I were > giving someone an editable vocabulary list in text because they were > an 'integrator/administrator', I'd write a Vocabulary object that used > something like YAML. Or CSV if that's what the user that's meant to > maintain it is. But I'm not going to turn over site.zcml or > overrides.zcml with all of its other crap just to let a secretary add > an airport code to a "preferred destinations" vocabulary. > > There's nothing in the Zope 3 implementation stopping you from having > the definition come in from outside. But don't restrict me from using > Python just to make a bone stupid simple list of values when I have > 100% or even 80% surety that it's *not* something that needs to be an > editable policy. It's a waste of time, it's another layer of > confusion, and as I said above: this is another policy thing that may > not even be maintained by any 'administrator/integrator'. So if there > was just one concept of a registered Vocabulary: that of a named > utility providing the IVocabulary (or a derivative) interface, then > it's easy: write one for your integrators/administrators that sources > itself from ZCML, OPML, RDF, whatever. I don't need it. For me, it > becomes a maintenance nightmare, or just a roadblock early on. > > So maybe I am blind. But I **absolutely do not need to worry about > integrators/administrators**. And I absolutely hate wasting time > writing something that hurts me to write and maintain for a role that > I, nor my colleagues, nor my customers, really have to play. Maybe you > do. But then, you should do like I do and build yourself some > frameworks on top of Zope that suit your world, your customers needs, > etc, and work through those. Don't make me have to jump through hoops > and XML pain just to make a "yes/no/maybe" option list just because > there's this theoretical person out there that might want to add a > "maybe not" after they find it buried deep within the trenches of XML > files buried in an Egg. So *don't use ZCML*; use Python: there is literally nothing which can be done in ZCML which cannot be done in Python. I wish that folks who don't like / need ZCML would quit trying to dictate how the rest of us use ZCML. Or, if you like ZCML but don't like the current directive set, feel free to propose a new set of directives you think are better, and implment them in *your* namespace: if enough other people like them, we can talk about making people who are already using the current set change. But let's quit tearing up what people have alredy learned in favor of a it-must-be-better-because-its-new variant which doesn't yet exist, and whose improved usability we have to take on faith. I'll note that the "Refactor mercilessly" meme from XP is *not* particularly well-suited to frameworks / libraries: it is best suited when applied to *applications*, where the impacts of such changes are borne entirely by the people who make them. When you tear up the API of a framework / library, you force *other* people to make changes, often without any particular benefit to them. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHvlc+gerLs4ltQ4RAkGoAJwMlUixk+yOo1wLjag8vX394zPRbgCfX8A3 9xtrj5J+Vc4Qcut51Arx3DM= =JGRT -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: [Zope-CMF] Fighting the Zope 2.9 testrunner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Chris Withers wrote: > >> Jens Vagelpohl wrote: >> >>> >>> From the old testrunner, which I miss *a lot*, I could ensure I am >>> indeed running a specific module by doing... >> >> >> >> Yup, this is one of the things I like least from the Zope 3 world. >> What happened to proposals and community agreement before inflicting >> big changes on other people who're trying to help out? > > > Oh cut the crap. The new test runner tries very hard to be backward > compatible. The old test runner was increasingly unmaintaiable and > had a host of bugs of it's own. > > I can't tell what you snipped, but I'm guessing that it was the > breakage of supplying a module name as a positional argument. > This breakage was not intentional. It was a bug. There is an > easy work around: just use the -m option. > >> I particularly hate the fact that no real effort was put into >> backwards compatibility, not to mention those silly weird >> sort-of-fifty-dots-per-line thing that doesn't actually work. I'm not sure what Chris meant, but the change to the visual output of the testrunner when running "with dots" seems gratuitous to me, as well - -- I don't see any benefit to the "indented, narrower" output, especially because it's "prettiness" gets fouled up anyway by deprecation warnings, etc. I objected to the change enough to file collector issues: http://www.zope.org/Collectors/Zope/1958 http://www.zope.org/Collectors/Zope3-dev/493 > What the heck are you talking about? What doesn't work? Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) to the choice to bolt on^H^H^H^H^H^H^Hretrofit zpkg. E.g.: $ cd /tmp $ svn co svn+ssh://svn.zope.org/repos/main/Zope/trunk zt $ cd zt $ ./configure --prefix=/tmp/zt-sw && make && make install ... running install_scripts error: cannot copy tree 'build/scripts-2.4': not a directory make: *** [install] Error 1 $ make clobber inplace ... $ ls -laF bin ls: bin: No such file or directory (The 'bin' directory was, in Zope 2.7, 2.8, the location for the scripts, created during an inplace build). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEH/jP+gerLs4ltQ4RAhlOAKDBNhLZNaLvUn9bHOTBiIjBz2CYLQCeI6gp WD21iz7SSHQfCTOd0PxT22s= =k4TY -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: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: > On 3/20/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > >>So *don't use ZCML*; use Python: there is literally nothing which can >>be done in ZCML which cannot be done in Python. I wish that folks who >>don't like / need ZCML would quit trying to dictate how the rest of us >>use ZCML. > > > "Literally nothing"? Try literally everything. I'm sorry. But that was > the experience I had that set me in such a bad temperament. I had no > idea what half of these directives were doing, and when trying to > duplicate them in a test environment I nearly threw the laptop to the > ground and swore of programming forever. I was *INCREDIBLY* > frustrated. There is a lot of potentially valuable functionality > *hidden behind ZCML*. If a ZCML directive were a one line > wrapper/adapter around a common function, I'd feel different. If a directive is too magical for you, and you don't mind writing Python, then *don't use it*. Consider the following: If you consider what it does (register a view which uses a filesystem-based template) rather than how it does it (i.e., synthesize a new class for use as a view factory and bind a template to it). If you don't like the implementation, and don't mind the boilerplate, then why not write: class MyView(object): index = zope.pagetemplate.pagetemplatefile.PageTemplateFile( 'templates/myview.pt') def __init__(self, context, request): self.context, self.request = context, request def __call__(self, *args, **kw): return self.index(*args, **kw) zope.security.checker.defineChecker(MyView, zope.security.checker.CheckerPublic) zope.component.provideAdapter( (ISomeInterface, zope.publisher.interfaces.browser.IBrowserRequest), MyView, 'myview.html') Note that I am *not* arguing in favor if the current implementation of / ; in fact, I think it is needlessly complex. But I am strongly against the idea of tossing the directive on that account, and thereby breaking deployed applications. > My argument and wish has been only this: simplify ZCML. Make it more > transparent what it is doing. There is a classic tension here between "convenience" and "purity". Please recall the many of the directives in ZCML were *added* because people got tired of typing repetitious boilerplate (imagine the Python code above repeated *dozens* of times in a given application). >>Or, if you like ZCML but don't like the current directive set, feel free >>to propose a new set of directives you think are better, and implment >>them in *your* namespace: if enough other people like them, we can talk >>about making people who are already using the current set change. But >>let's quit tearing up what people have alredy learned in favor of a >>it-must-be-better-because-its-new variant which doesn't yet exist, and >>whose improved usability we have to take on faith. > > > My set of directives is , , , and maybe > . Inside of , , , , > and (because I do believe that 'factory' there is a nice > shortcut). So just use those. But *don't* argue that the rest of us mustn't define or use more convenient directives. > Nothing new. Only less. Less concepts to have to remember. Less > concepts to have to look up. Less code to have to try to follow when > it's 10:30 at night and I've been working six hours too long and I > still can't figure out why my field adapter on an IChoice isn't > getting its value set properly and I can't get a vocabulary > bootstrapped up to write a test to debug and then verify the fix of > it. > > Make ZCML do whatever you want. But if you're going to share it, it > needs a HELLUVA lot better documentation. I'm glad for what's there > now. But I've been surprised by ZCML one time too many, and have lost > too many hours trying to figure out the surprise. Too many similar > directives, too many possible attribute combinations, and too little > information about what certain choices will actually do or what > they're good for. And the source is not a readable, reliable backup > point to look at. > > >>I'll note that the "Refactor mercilessly" meme from XP is *not* >>particularly well-suited to frameworks / libraries: it is best suited >>when applied to *applications*, where the impacts of such changes are >>borne entirely by the people who make them. When you tear up the API of >>a framework / library, you force *other* people to make changes, often >>without any particular benefit to them. >
[Zope3-dev] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Tres Seaver wrote: > ... > >> I'm not sure what Chris meant, but the change to the visual output of >> the testrunner when running "with dots" seems gratuitous to me, as well >> - -- I don't see any benefit to the "indented, narrower" output, >> especially because it's "prettiness" gets fouled up anyway by >> deprecation warnings, etc. I objected to the change enough to file >> collector issues: >> >> http://www.zope.org/Collectors/Zope/1958 >> >> http://www.zope.org/Collectors/Zope3-dev/493 > > > Your objections are and were noted. I don't really > care about the format. I thought I had improved the output > at the time. I find the new format easier to read myself > but I really don't care. If people would prefer a different > format, someone please change it. > > What's really depressing about this is that we are spending > so much energy and angst over the layout of dots. Especially as you usually run tests without them. ;) >> >>> What the heck are you talking about? What doesn't work? >> >> >> >> Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) > > > What does that have to do with the test runner? I thought that there was some disussion of a broader theme: "2.9 breaks stuff that Zope 2 developers expecdt", of which the testrunner changes one example. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEIW8P+gerLs4ltQ4RAn0JAKC/ukcRbPSR929dg4UqKtvwLg6o8QCfSBaO keexxXjQJ4gQ+G/VSOqrWnk= =rGJb -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: set of interfaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Marc Orliaguet wrote: > what is the best way in zope3 to create a collection of interfaces > without using classes, lists, etc.? > > I have a number of interfaces that I'd like to group into a same > interface category. > > e.g. ISomeCollection = I1, I2, I3, I4 > > and I'd like to be able to query which interfaces ISomeCollection > "contains". However I'd like not to instanciate a registry just to > hold that type of information. You can create a Specification object from a sequence of interfaces: >>> from zope.interface import Interface >>> class I1(Interface): pass ... >>> class I2(Interface): pass ... >>> class I3(Interface): pass ... >>> from zope.interface.interface import Specification >>> spec = Specification((I1, I2, I3)) >>> I3.providedBy(spec) False >>> I3.implementedBy(spec) False >>> spec.extends(I3) True >>> [x for x in spec.interfaces()] [, , ] Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEIXM3+gerLs4ltQ4RAjL0AKClFxW5r9tl5dy2AL8uuzsjrNLVWgCeP75E tHJVvc6iWhhfkDTYOEag2ic= =hAiX -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: [Zope-CMF] Fighting the Zope 2.9 testrunner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Philipp von Weitershausen wrote: > >> Tres Seaver wrote: >> >>> I'm not sure what Chris meant, but the change to the visual output of >>> the testrunner when running "with dots" seems gratuitous to me, as well >>> -- I don't see any benefit to the "indented, narrower" output, >> >> >> Me neither, for what it's worth. > > > Okay, Tres, can you give me a line number I can poke at to remove this? > It seems like Jim doesn't care too much, and I see 3 people at least who > don't like it. The collection issues have patches: http://www.zope.org/Collectors/Zope/1958 http://www.zope.org/Collectors/Zope3-dev/493 >>> Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) >>> to the choice to bolt on^H^H^H^H^H^H^Hretrofit zpkg. >> >> >> Sort of. It didn't break configure && make. It's just "make install" >> that was broken. And 'make inplace'. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEIrPy+gerLs4ltQ4RAiwvAKCszyiu1tL0CyBFeJju3uqiq6/I4QCfaKwt nlzrTYJU4URHluxG6WtZa1c= =YRhF -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: eggifying zc.resourcelibrary, zc.table and others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: > > On Apr 4, 2006, at 12:38 PM, Martijn Faassen wrote: > >> Hi there, >> >> * does anyone have any objections if I make eggs for various zc.* >> packages? In svn, this involves adding a setup.py to these packages, >> and to add a __init__.py to the zc package that they contain (which >> contains some egg-specific stuff). > > > Sounds great! (I assume the __init__ changes won't cause problems > without setuptools around). There is supposed to be a dance in Python itself for declaring a namespace package. Framkly, anybody who wants to play along *without* setuptools installed has rocks in their heads: distutils is too wanky to use by itself for "complicated" cases, and setuptools makes it just barely tolerable. > Jim points out that Nathan Yergler has a > script that can generate eggs from zpkg data; you might or might not > find that to be easier. It's less of an obvious win with these > packages that have little or no zpkg metadata already, but it might > still be quicker in some cases (no idea myself). > >> >> * the setup.py I'll create will only work with setuptools installed; >> is this a problem? > > > Not from us. You'd maybe get even more warm fuzzies from people by > making it not require setuptools, but that limitation doesn't bother us. > >> >> * what email address should I list for the author of some zc package? >> this is information that will appear in the cheeseshop. > > > zope3-dev@zope.org > >> >> * to get the full egg experience, I'd like to have them uploaded to >> the cheeseshop. I could do this myself, but they're not my packages. >> Can I? or does someone else want to do this? I'll of course gladly >> give admin rights for these packages to the real creators. > > > Jim also suggests the new, as-of-this-moment-no-longer-secret http:// > download.zope.org/distribution/ as a possible location instead. All > Zope committers have the appropriate privileges to scp to this > directory. That's where he will be doing his egg work, at least until > he thinks we have figured out the best way to make Zope eggs. It can > be used a setuptools source. Note that I am actively working in that directory on eggifying a number of the "top-level" zope packages in "released" verisons (typically in the flavors which shipped with ZopeX3.0.0 and Zope3.2). > If you want to use the cheeseshop anyway, that's ok too. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEMsG5+gerLs4ltQ4RAq4rAKDCwrsDs/nmkJVv7ASzuhLsa81LOQCeIt6/ mBewTTCRqCgcK5EjiAO039U= =GITX -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: eggifying zc.resourcelibrary, zc.table and others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Gary Poster wrote: > [snip] > >> Jim also suggests the new, as-of-this-moment-no-longer-secret http:// >> download.zope.org/distribution/ as a possible location instead. All >> Zope committers have the appropriate privileges to scp to this >> directory. That's where he will be doing his egg work, at least >> until he thinks we have figured out the best way to make Zope eggs. >> It can be used a setuptools source. > > > I'm trying to find a way to scp the zc.resourcelibrary egg into it, but > I get permission denied when I scp, possibly because I don't know which > directory 'distribution' really is on the actual system. /var/www/download.zope.org/distribution Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEM7Oj+gerLs4ltQ4RAgGJAJ9VPqycNaXuPyfSEfm0rWvJhSlQJQCfbsFo 8w3i1nRqZ2pnWXm4QyF+6g4= =OKT/ -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: eggifying zc.resourcelibrary, zc.table and others
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
>>> * the setup.py I'll create will only work with setuptools installed;
>>> is this a problem?
>>
>>
>> Not from us. You'd maybe get even more warm fuzzies from people by
>> making it not require setuptools, but that limitation doesn't bother us.
>
>
> Okay, good. Warm fuzzies are nice, but I won't worry too much about that.
There is some support for "kickstarting" an eggifying project. E.g.:
$ export ZSVN=svn+ssh://svn.zope.org/repos/main
$ svn cp -m "Eggify" $ZSVN/productsupport/trunk/project-template \
$ZSVN/zope.foopackage
The top-level 'zope.foopackage' will have a skeleton 'trunk', plus empty
'branches' and 'tags':
$ svn co $ZSVN/zope.foopackage/trunk zope.foopackage-trunk
$ cd zope.foopackage-trunk
$ ls -1
CHANGES.txt
develop.py
INSTALL.txt
README.txt
setup.cfg.in
setup.py
src
test.py
workspace
The text files are templates, and should be edited to fit.
The 'develop.py' script will set up a local 'bin' and 'lib' directory
inside your checkout, and try to install dependencies as specified in
'setup.py' and 'setup.cfg' (which it copies from 'setup.cfg.in'). It
also jams the Zope egg URL into 'setup.cfg'.
I usually run 'setup.py develop' afterwards, as it is better at
finding all the dependencies:
$ PYTHONPATH=lib /path/to/your/python setup.py develop
The 'zope.testing' package is supposed to be pulled in during that
bootstrapping, but often seems missed (I haven't yet figured out
why). Running the local 'easy_install' does the trick:
$ PYTHONPATH=lib /path/to/your/python bin/easy_install \
zope.testing
The 'src/zope' directory is intended to contain a 'svn:externals'
pointer to the "canonical" location of the source (we may eventually
reverse this, and make the main Zope tree point out at the top-level
package directories). E.g.
$ svn propedit svn:externals src/zope
#... add your external here
$ svn up
# ... fetches your external.
That 'src/zope' directory also contains "setuptools / pkgutil"
boilerplat namespace __init__.py:
$ cat src/zope/__init__.py
# namespace package boilerplate
try:
__import__('pkg_resources').declare_namespace(__name__)
except ImportError, e:
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
The 'test.py' needs to be edited to point to your package. At that
point, you should have all your package's dependencies installed
(assuming that you named them in 'setup.py'), and should be able to run
the tests using your local eggs:
$ PYTHONPATH=lib /path/to/your/python test.py
Nathan, Jim, please correct any mistakes you see.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEM7tX+gerLs4ltQ4RArrjAJ9GAW9klbLC9n4ZUdcmbvvsrSDQCgCgsz+l
SojySIyJZEGgMVercdKH8Uk=
=FdIS
-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: [Checkins] SVN: Zope3/trunk/src/zope/app/form/browser/itemswidgets.py The label for the list items widgets could not point to the field, because
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: > > On Apr 5, 2006, at 4:14 PM, Kamal Gill wrote: > >> Hmm, I'm inclined to doubt whether IE expects the id and name >> attributes to be identical. Distinct values for id and name >> shouldn't be a problem, afaik > > > Wait, someone used "shouldn't be a problem" in reference to IE? :-) > > As Benji said, this isn't idle: we've encountered some pain that makes > me bring this up. A quick Google search didn't come up with any > confirmation, though, so, without further backup, I'm happy to let this > lie. I'm pretty sure that at least some flavors of IE were fussy about 'id' attributes which were not valid according the HTML DTD's; I therefore quit giving form fields an 'id' attribute long ago, just because I couldn't keep it straight. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENFJc+gerLs4ltQ4RApmfAKCFRB3tvLCbNXRarJ96hoxeGTCvagCeOHTc /GpIl9O6n4uAbJ7r5HDMeLo= =jcyG -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: [Zope3-dev] Re: eggifying zc.resourcelibrary, zc.table and others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Gary Poster wrote: > [snip] > >> Apologies for the confusion, Martijn. I checked with Jim. The >> procedure that Tres described is only for people who have direct >> access to the machine. The intended use is similar to the following: >> >> $ touch gary_test.txt >> $ scp gary_test.txt [EMAIL PROTECTED]:/distribution/ >> gary_test.txt 100%0 0.0KB/s >> 00:00 >> > > That appears to have worked! Thanks! Now somebody needs to remove the > martijn_test.txt again, unless scp has file removal capabilities I don't > know about. :) Done. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENPbA+gerLs4ltQ4RAjR2AKDBGRc2b2Rkv5sI+EmPeTMZbecqiQCglq2r IwFGz0GQ2IszgDI6MGHZHG4= =rCZs -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: Insufficient Privileges when adding a patch in the collector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjorn Tillenius wrote: > I tried to add a patch to a bug in the collector, but I was presented > with a page saying that I don't have sufficient privileges to view this > page. Do I need some special privileges to attach a file to an issue? For issues created by others, you need either to ba a "supporter" for the collector, or else have the "Owner" local role granted. I just made you an "Owner" of the Z3-dev issue 448; if you would prefer to be a suppoerter (you will get e-mail about all issue traffic in the collector, in that case), please let me know. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPQxr+gerLs4ltQ4RAkGUAJ9W0v86oT8C7Wz3X10xOgwTCUUWvACffne2 OzvDuVV0gsL7/9BXHXSr1wQ= =Bug1 -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: 64-bit BTrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), > and I'm not the first. I've created a feature development branch for > this, and checked in my initial implementation. > > I've modified the existing code to use PY_LONG_LONG instead of int for > the key and/or value type; there's no longer a 32-bit version in the > modified code. Any Python int or long that can fit in 64 bits is > accepted; ValueError is raised for values that require 65 bits (or > more). Keys and values that can be reported as Python ints are, and > longs are only returned when the value cannot be converted to a Python > int. > > This can have a substantial effect on memory consumption, since keys > and/or values now take twice the space. There may be performance > issues as well, but those have not been tested. > > There are new unit tests, but more are likely needed. > > If you're interested in getting the code from Subversion, it's available at: > > svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ > > Ideally, this or some variation on this could be folded back into the > main development for ZODB. If this is objectionable, making 64-bit > btrees available would require introducing new versions of the btrees > (possibly named LLBTree, LOBTree, and OLBTree). I think coming up with new types is the only reasonable thing to do, given the prevalence of persistent BTrees out in the wild. Changing the runtime behavior (footprint, performance) of those objects is probably not something which most users are going to want, at least not without carefully considering the implications. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPpyu+gerLs4ltQ4RAmh1AJ9/dLigNMrQgIFNASKWbpvboapywwCePV22 /3d8kFGTjipAVCsy5fnuLa4= =xe6v -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: [Zope-dev] Re: 64-bit BTrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Tres Seaver wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Fred Drake wrote: >> >>> I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), >>> and I'm not the first. I've created a feature development branch for >>> this, and checked in my initial implementation. >>> >>> I've modified the existing code to use PY_LONG_LONG instead of int for >>> the key and/or value type; there's no longer a 32-bit version in the >>> modified code. Any Python int or long that can fit in 64 bits is >>> accepted; ValueError is raised for values that require 65 bits (or >>> more). Keys and values that can be reported as Python ints are, and >>> longs are only returned when the value cannot be converted to a Python >>> int. >>> >>> This can have a substantial effect on memory consumption, since keys >>> and/or values now take twice the space. There may be performance >>> issues as well, but those have not been tested. >>> >>> There are new unit tests, but more are likely needed. >>> >>> If you're interested in getting the code from Subversion, it's >>> available at: >>> >>>svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ >>> >>> Ideally, this or some variation on this could be folded back into the >>> main development for ZODB. If this is objectionable, making 64-bit >>> btrees available would require introducing new versions of the btrees >>> (possibly named LLBTree, LOBTree, and OLBTree). >> >> >> >> I think coming up with new types is the only reasonable thing to do, >> given the prevalence of persistent BTrees out in the wild. Changing the >> runtime behavior (footprint, performance) of those objects is probably >> not something which most users are going to want, at least not without >> carefully considering the implications. > > > It really depends on what the impact is. It would be nice to get a feel > for whether this really impacts memory or performance for real > applications. > This adds 4-bytes per key or value. That isn't much, especially in a > typical > Zope application. Similarly, it's hard to say what the difference in C > integer > operations will be. I can easily imagine it being negligible (or being > significant :). > > OTOH, adding a new type could be a huge PITA. We'd like to use these > with existing > catalog and index code, all of which uses IIBTrees. If the performance > impacts are > modest, I'd much rather declare IIBTrees to use 64-bit rather than > 32-bit integers. > > I suppose an alternative would be to add a mechanism to configure > IIBTrees to use > either 32-bit or 64-bit integers at run-time. Who uses IOBTree / OIBTree / IIBTree? - Catalogs map RIDs to UIDs as IOBTrees (one record per indexed object) - Most indexes (those derived from Unindex) map RID to indexed value as an IOBTree (one record per object with a value meaningful to that index) and map values to RIDs as OOBTrees (where the second O is usually an IITreeSet). - ZCTextIndex uses IIBTrees to map word IDs to RIDs, in various ways, and make use of IOBTrees as wel.. - Relationship "indexes" (typically not stored within catalogs) usually have an IIBTree which is the mapping of the edges as pairs of internal node IDs (one per explicit relationship), with OIBTrees to map the user-supplied node value to a node ID. I would guess that if you could do a census of all the OIDs in all the Datas.fs in the world, a significant majority of them would be instances of classes declared in IOBTree / IIBTree (certainly the bulk of *transaction* records are going to be tied up with them). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPtfe+gerLs4ltQ4RAkDoAJ9998Bj5yMqVpKoQOn/s3Hf5GZkBwCcC4uY kXTqmBsu6vMYx4fzAOWF5uo= =yVVq -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: [Zope3-dev] Re: 64-bit BTrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > Previously Chris Withers wrote: > >>The implicit change to make them all 64-bits which results in some >>unknown slowdown for all "I" BTree users seems a bit too scary to bite >>off... > > > Has anyone done any benchmarks to prove that 64-bits is slower or > faster? It would be interesting to see benchmarks on modern 32bit > and a 64bit systems. Until then it's all hand-waiving. Sure, but the "burden of proof" needs to be on the party proposing the cnange. "First, do no harm" is a good principle in such cases. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFERpCv+gerLs4ltQ4RAuoIAJ9fKveUfI54DtYWnD9pWDudhqf5LACgmZu1 GFD9FgvQDR9BdvIyTpIm2tI= =QgmO -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: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> http://dev.zope.org/Zope3/TheBrowserPageCompromise
>
> I've long been thinking about how to make simpler and
> less magical. Some radical ideas weren't received well and I couldn't
> convince even myself 100% that they were the way to go. Other
> brainstormings were dead ends.
>
> I therefore call this proposal a compromise. It simplifies, but it
> shouldn't annoy (Tres...). Note that I'm specifically only addressing
> , not ; nor am I coming up with a
> framework for dealing with forms and their handlers (Jeff...).
>
> 'Nuff said. Your turn :)
- -1 on breaking ZCML in the wild. Propose *new* directives which have
new semantics, but for existing directives, we should clean up the
implementation rather than modifying semantics. E.g., we should be able
to rip out the gunk which synthesizes new classes in 'browser:page': I
think it derives from a period before we could assign a
'__Security_checker__' attribute to instances, and so *had* to have a
class in order to make the checker stuff work.
Here is an example from my 'pushpage' product, which has a directive for
registering pages using filesystem templates::
class PushPageFactory:
def __init__(self, template, mapper, checker=None):
if getattr(template, 'read', None) is not None:
template = template.read()
self.template = PushPageTemplate()
self.template.write(template)
self.mapper = mapper
self.checker = checker
def __call__(self, context, request):
page = PushPage(context, request, self.template, self.mapper)
if self.checker is not None:
page.__Security_checker__ = self.checker
return page
The directive handler instantiates the factory::
def pushpageViewDirective(_context,
for_,
name,
permission,
template,
mapping,
layer=IDefaultBrowserLayer,
):
""" Create and register factory for pushpage-driven views.
"""
if for_ is not None:
_context.action(
discriminator = None,
callable = provideInterface,
args = ('', for_)
)
if permission == 'zope.Public':
permission = CheckerPublic
template = os.path.abspath(str(_context.path(template)))
if not os.path.isfile(template):
raise ConfigurationError("No such file", template)
required = {'__call__': permission,
'__getitem__': permission,
'browserDefault': permission,
'publishTraverse': permission,
}
checker = Checker(required)
factory = PushPageFactory(open(template, 'r'), mapping, checker)
_context.action(
discriminator = ('view', for_, name, IBrowserRequest, layer),
callable = handler,
args = ('provideAdapter',
(for_, layer), Interface, name, factory,
_context.info),
)
Note this implementation does not require majyk classes -- the factory
instances here function in place of the synthesize classes.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFER8KA+gerLs4ltQ4RAh0kAJ9vvKtqAcPfZh0+2ujqpJefWGgsFQCeNzhi
r8E8Ewhpv/aJdP0t20vpZok=
=Z27s
-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: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Tres Seaver wrote: > >>-1 on breaking ZCML in the wild. Propose *new* directives which have >>new semantics, but for existing directives, we should clean up the >>implementation rather than modifying semantics. E.g., we should be able >>to rip out the gunk which synthesizes new classes in 'browser:page': I >>think it derives from a period before we could assign a >>'__Security_checker__' attribute to instances, and so *had* to have a >>class in order to make the checker stuff work. > > > It's not only the security checker. It's the whole IBrowserPublisher > implementation that's jerked into the subclass. My proposal is exactly > stopping that. > > Of course, we can implement new directives (possibly with the same name > but different namespace URI) and deprecate the old ones. But that's only > marginally different from what I propose. The difference is that your proposal *forces* people to change previously-working ZCML; that is the thing to which I am opposed. I think we have been too "deprecation happy" over the last few releases; in particular: - Introducing new deprecation warnings in "third-dot" releases is probably inappropriate: people shouldn't need to think about such issues during "normal maintenance" upgrades, where we explicitly promise API stability. - Deprecating an API without cleaning up *all* core uses is a *lie*; I would be strongly in favor of reverting *any* such cases as "premature." Some of the lies we have propagated here are also violations of my first tenet, which reinforces their inappropriateness. - Deprectaion of an older, stable alternative, *no matter how grotty,* should go hand in hand with *lots* of confidence that the new favored alternative really is superior, and by enough margin to make the switch worthwhile. In my mind, this means that the new implementation needs to be rolled out *in production* and tested in the wild *before* we can deprecate the older alternative. "Refactor mercilessly" is not a mantra which works very well for frameworks, particularly once they have rolled out with third party dependencies. Note that classic XP is specifially "framework averse", and comes out of a purlely leafmost / application-centric development model. It is also hostile to remote / dispersed development, which we routinely practice. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFER92N+gerLs4ltQ4RAscJAJ9/odAd+QLQ75PLznSIgKyqctY5zwCgp79V ZsMgT6G7slYBbfFXfqWBkL0= =6RBB -END PGP SIGNATURE- -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>
>> - Introducing new deprecation warnings in "third-dot" releases is
>> probably inappropriate:
>
>
> When we have we done this?
2.9.1 just did it (see below).
>> - Deprecating an API without cleaning up *all* core uses is a *lie*;
>
>
> In some of the few cases where this happened was oversight and not
> intentional. When you deprecate something, none of the core should still
> use it. I think that's pretty clear.
Zope 2.9.0 shipped deprecating the OFS.content_types module without
removing all uses (I cleaned that up back in January).
Zope 2.9.1 deprecated zLOG without removing all uses: testrunner output
is *still* littered with deprecation warnings for zLOG. As far as I'm
concerned, that means 'zLOG' is *not* deprecated in the 2.9.x release
line, and may not therefore be ripped out unitl the appropriate interval
*after* 2.10 (i.e., in 2.12, not 2.11).
>> - Deprectaion of an older, stable alternative, *no matter how grotty,*
>> should go hand in hand with *lots* of confidence that the new favored
>> alternative really is superior, and by enough margin to make the
>> switch worthwhile. In my mind, this means that the new
>> implementation needs to be rolled out *in production* and tested in
>> the wild *before* we can deprecate the older alternative.
>
> I think that's a big burden for refactorings. Under such a rule, Jim
> wouldn't be allowed to roll out neither his adapter registry
> improvements nor his Component Architecture simplification.
Refactorings *need* a bigger burden than we have recently been imposing:
- Doing a refactoring right means adding BBB code, which itself
increases the maintenance burden for core developers.
- As an example, the twisted server became the *default* in Zope 3.2
in spite of the fact that it broke ZEO because the developer who
landed the change doesn't use ZEO, and hence missed seeing the
damage.
- The packaging changes introduced in the 2.9 release cycle broke
usecases which many developers care about ('make inplace' is broken,
instance home testing broke, etc.) Worse, and ironically, the
breakage was incurred on behalf of 'zpkg', which is itself slated
(now) to be deprecated.
- Jim's current changes will most likely land for 2.10. If we don't
spend enough time in the beta cycle with them, we may be seeing
similar effects, or may need to be prepared to "un-deprecate" some
of the stuff currently on the doomed list.
> We're not "refactoring mercilessly." We're thinking about problems,
> writing proposals, measuring risks, providing BBB and writing tests.
> We'll have to trust our tests to a certain degree. If we don't then
> perhaps we need more tests. We surely could use more functional tests.
>
> I'll be fine with creating new directives instead of changing the old
> ones, if that's what the majority prefers. But then I'd very much like
> to see a Death Certificate for the old directives made out for some time
> in the future (doesn't have to be 2 releases, could be more).
I don't think we are going to come to consensus about the appropirate
"standard set" of directives anytime soon: the current state of the
debate reminds me eerily of the "lumbers" vs "splitters" rift in the
world of paleoanthropology[1], which has been unresolved for more than a
generation now.
I stand by my claim that the "reductionist" strain in our current debate
is backed by developers who *also* admin the systems they have deployed,
and that this sample is not representative of the audience to whome Zope
is pitched.
[1] http://www.mos.org/evolution/downloads/desilva.html
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFER/Gj+gerLs4ltQ4RAu16AKDBkOGl3aoBIAVBQwUciAMwxRsUeQCfXv8u
7/D6eKGh5DO0uqJyvC5U1hU=
=tS58
-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: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>
>>>>>- Deprectaion of an older, stable alternative, *no matter how grotty,*
>>>>> should go hand in hand with *lots* of confidence that the new favored
>>>>> alternative really is superior, and by enough margin to make the
>>>>> switch worthwhile. In my mind, this means that the new
>>>>> implementation needs to be rolled out *in production* and tested in
>>>>> the wild *before* we can deprecate the older alternative.
>>>>
>>>>I think that's a big burden for refactorings. Under such a rule, Jim
>>>>wouldn't be allowed to roll out neither his adapter registry
>>>>improvements nor his Component Architecture simplification.
>>
>>Refactorings *need* a bigger burden than we have recently been imposing:
>>
>> - Doing a refactoring right means adding BBB code, which itself
>>increases the maintenance burden for core developers.
>>
>> - As an example, the twisted server became the *default* in Zope 3.2
>>in spite of the fact that it broke ZEO because the developer who
>>landed the change doesn't use ZEO, and hence missed seeing the
>>damage.
>
> I guess we didn't have enough tests. Now we have a test that exercises
> ZEO. Plus, we dealt with this problem before any final release (perhaps
> even before the beta?). That's what alpha and beta phases are for...
My point here is that the 'refactor mercilessly" meme has left people
feeling free to make chnages of debatable value (Twisted is *still* not
accepted in the Zope community as a superiour choice for publishing
HTTP), without full weight being given to the needs of folks who aren't
up to their elbows in the code every day.
>> - The packaging changes introduced in the 2.9 release cycle broke
>>usecases which many developers care about ('make inplace' is broken,
>>instance home testing broke, etc.) Worse, and ironically, the
>>breakage was incurred on behalf of 'zpkg', which is itself slated
>>(now) to be deprecated.
>
> Forgive me if I'm a little rough on this subject, but here it goes:
>
> I've had it with this whining about make inplace etc. It's been nearly
> half a year since 2.9 is out and nobody has even made the attempt to fix
> this so I guess nobody really needed it. Yet there's still whining. Yes,
> I'm to blame for bringing zpkg to Zope 2 because the Zope 3.2 build
> process strongly suggested it. If there were alternatives to zpkg,
> nobody has suggested them and nobody seems to have explored them so far.
> All I know is that everyone wanted Zope 3.2 in Zope 2.9 which is what
> they got.
Zope 3 is a *library* for Zope 2 -- I don't see any necessary reason to
have Zope 3's packaging model drive Zope 2's. What I recall about this
discussion was the following:
- There was distaste in the Zope 3 world for the carefully
hand-maintained code which made Zope 2's 'configure && make && make
install/inplace' dance work
- Jim proposed ripping it out in Zope 3 in favor of the "generate
everything via zpkg' dance.
- In order to "move toward the Zope 3 way", you proposed doing the
same for Zope 2.9.
- Immediately after you landed the change, folks began to point out
issues with it
o in-place builds were broken (the 'bin' directory was not created)
o out-of-tree builds broken (e.g.:
$ sudo mkdir /opt/zope29
$ sudo chown tseaver:root /opt/zope29
$ cd /opt/zope29
$ /path/to/zope29/checkout/configure && make && make inplace
o 'make instance' and 'mkzopeinstance' producing borked instances,
(since fixed for 2.9, but still broken in Zope 3)
- We stayed the course, and *today* are still stuck with a 2.9 branch
which *cannot be used* as the 2.8 branch was in a checkout. The
problem appears to be intractable, as the changes needed to make
'zpkg' work completely invalidated all our former experience and
knowledge of how to use a checkout tree.
Effectively, the only folks who can maintain the 'zpkg'-centric
build don't care about these usecases, and so we are stuck.
- Not only that, but we did it to support 'zpkg', which has proved to
be a failed experiment, even for packaging Zope 3. For instance,
at this point, a Zope 3.2 checkout tree can be uesd to do only:
o Run the unit tests.
o Generate a "release distribution".
It cannot be used as the basis for running developer sandboxes, a
[Zope3-dev] Re: [z3-five] Re: Patch for testbrowser.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: > On Fri, Apr 21, 2006 at 04:07:43PM +0200, Daniel Nouri wrote: > >>The relevant code in Zope2's ZPublisher.HTTPResponse.__str__: >> >># ... we just built a headersl list using self.heders >>if self.cookies: >>headersl = headersl+self._cookie_list() >>headersl[len(headersl):] = [self.accumulated_headers, body] >>return '\n'.join(headersl) >> >>Maybe this can shed some light on whether we want to include that patch. > > > As an aside: > > What's with assigning to headersl[len(headersl):] instead of calling > headersl.extend(...)? > > I've seen this idiom a couple of times and I always wonder > why, it's much less readable IMO. > > I doubt it's supposed to be an optimization, since this code runs only > once per request; anyway, the two idioms are about equivalent in speed > AFAICT. > > If it were in a performance-sensitive loop, a bit faster > and still quite readable would be: > > headersl += [self.accumulated_headers, body] > > timeit confirms this, here on python 2.4.2: I think this may be a fossil from a much earlier version of Python, in which 'list.extend' had undesirable performance (the new one is O(1)-amortized, I think). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFESVJ5+gerLs4ltQ4RAlseAKDVL5ABbRYGSzNtaLUVeu37WPTBCwCfW9pp c1gst1YN+xssxW2ZFhHWt88= =bcvP -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: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Bernd Dorn wrote:
>
>>>http://dev.zope.org/Zope3/TheBrowserPageCompromise
>
>
> [snip]
>
>
>>-1
>>
>>In the Proposal you say:
>>
>>"Why is this a problem? Because certain behaviour is mixed into the
>>class created on-the-fly. This behaviour is not apparent in our view
>>class, yet we assume it exists. It's magic."
>>
>>For me this is not a reason to change/add directives. This just results
>>in more work for keeping track with the zope3 releases in
>>client-projects. It is ok to improve things, but this is no improvement
>>for end users IMHO.
>
>
> If I saw no improvement for the end user, I would certainly not have
> written this proposal. The maintainability of the current code (which is
> horrid) is just a very minor factor.
>
> The dynamic creation of new classes make it *very* hard to understand
> what's going on:
>
> * Page classes don't need an __init__ or anything like that, it's
> received magically.
>
> * Page classes don't need to bear any notion that they are going to be
> publishable. This has led to the lack of understanding (among core
> developers!) what the difference between a mere browser view and a
> browser page is. (This is probably the best "proof" that the current
> system is confusing and lacks clarity.)
>
> * The resulting class doesn't exist anywhere (because it's dynamically
> created). This makes debugging very hard. See example mentioned in
> http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html.
>
> Perhaps I should mention these points in the proposal. I will update it
> later.
I would point out that the *existence* of the new class is an
implementation detail, of which end users can remain blissfully
ignorant. The users who get bit are the ones who want *both* the
convenience of the current directive's semantics *but* want to be able
to override some of the ways those "implementation details" work. Such
users probably need to forego the convenience, and settle instead for
implementing their *own* directive, which does what they want.
I would argue, BTW, that if we are going to get rid of directives,
'browser:view' is a lot better candidate than 'browser:page': I would
bet that 99% of the third-party Zope3 application code in the wild
*never* users 'browser:view', and that the authors of the 1% are the
same ones who are involved (or should be) in this debate.
>>This reminds me of the deprecation of the vocabulary
>>directive, which is also just a burden for end users (i've missed that
>>discussion).
>
> Any deprecation is a burden on the "end user" in the sense that code has
> to be fixed. We can't get anywhere if we don't accept that.
We need to take that cost into account more clearly, because we are
trading off *other people's cossts* for our own benefit (increased
maintainability, new features, or "I just like it better").
>>and:
>>"""Browser "pages" are essentially just adapters to the Component
>>Architecture. Implementation details (template or not, etc.) should not
>>be of much interest during the registration."""
>>
>>I don't think that the template is an implementation detail. IMHO For a
>>high level user the adapters are an implementation detail.
>
>
> I'm not quite sure what you mean by that. To the publisher, to the
> comopnent architecture and to ZCML, the fact that a browser page is
> using a Page Template or something else to render HTML should be
> immaterial. It's an implementation detail of the browser page itself.
It is *not* an implementation detail for the application develo9per: it
is part of the public API of the directive. I would bet again that the
percentage of "deployed-in-the-wild third-party-application directives"
which do *not* use templates is *tiny*.
> Example::
>
> class HelloPage(zope.formlib.Page):
> def __call__(self):
> return u'Hello World'
>
> class HelloTemplatePage(zope.formlib.Page):
> __call__ = ViewPageTemplateFile('helloworld.pt')
>
> class HelloWhatEverPage(zope.formlib.Page):
> def __call__(self):
> return something_that_is_html
>
> To ZCML, these pages are all the same. It shouldn't matter to ZCML
> what's behind a page.
Directives matter to the *user*; what the underlying wiring ends up
looking like is *irrelevant* to the user, as long as the semantics are
satisfied.
Tres.
- --
=
[Zope3-dev] Re: Update: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Florent Guillaume wrote:
>
>> Philipp von Weitershausen wrote:
>>
>>> If people don't like the 'browser2' prefix, I'm open to other
>>> suggestions. For all I care, the three directives I suggested could
>>> be on the 'browser' namespace, only browser2:page and browser:page
>>> clash. So perhaps browser2:page should be named something else. I
>>> can't seem to come up with good alternatives, though.
>>
>>
>> I haven't looked closely, but can't we have one whose
>> behaviour changes according to what attributes it has? If old
>> attributes are provided, a deprecation message is sent but the old
>> code is used. Otherwise the new behaviour is in effect.
>
>
> Heh, of course. In fact, that was my original idea, but Tres & Co.
> objected to it (changing browser:page in-place instead of creating a new
> directive).
There is no particular reason to have the new directives in the same
namespace as the old ones, but note that the "convenience prefix"
('browser' vs. 'browser2') is strictly up to the author of the ZCML
file, and not up to the directive author.
Changing the namespace declration at the top of that file would be a
sign that one had adopted the new semantics, which seems like a good
gesture to me.
If we don't adopt a new namespace, perhaps 'browser:published'would
serve as a 'nominalized adjective" noun form of 'browser:publish'.
In any case, I would argue for having the new directives deployed as
alternatives for at least a release *before* we talk about deprecating
the old ones.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFETPPr+gerLs4ltQ4RAlVrAJ9oc7be5KfBUJE18IkHd02kwDM3rQCgssxu
IMcJnwDkvchb7Wj13Fft84M=
=CX7u
-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: ClientStorage vs DemoStorage broken in Zope 3.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > Hi, > > I'm preparing a presentation and marketing campaign for Zope 3 for the > next weeks linux fair in here in Germany. I'm demonstrating a couple of > things and was trying to use DemoStorage with ClientStorage on a Zope > 3.2 server today. However, it didn't work and crashed with this message > and traceback (partially given): > > File "/home/ctheune/Development/Zope-3.2/src/ZODB/DemoStorage.py", > line 94, in __init__ > BaseStorage.__init__(self, name, base) > File "/home/ctheune/Development/Zope-3.2/src/ZODB/BaseStorage.py", > line 108, in __init__ > self._oid = base._oid > AttributeError: 'ClientStorage' object has no attribute '_oid' > > > Is this something that > > - should not be broken > - should be fixed > - is known > > ? > > I'd fix it if someone gave me a quick hint on what is wrong. Smells like a fix didn't get forward-ported somehow -- that looks like the same error I helped Tim find and fix for Zope 2. CC'ing the ZODB list just in case anyone there has a better memory. Here is the NEWS.txt entry for that fix: DemoStorage --- - (3.4a4) Appropriate implementations of the storage API's ``registerDB()`` and ``new_oid()`` methods were added, delegating to the base storage. This was needed to support wrapping a ZEO client storage as a ``DemoStorage`` base storage, as some new Zope tests want to do. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFETu39+gerLs4ltQ4RAtGBAJ0Thb6eJPegItQr9HDHvtskfXsIJwCfSgRM 0V1ma6vIS67f/Osxko7wkNc= =9S/w -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: Zope-3.2.1.tgz Zope version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshito Komatsu wrote: > Hello, > > Zope-3.2.1.tgz does not have the version.txt in src/zope/app, > so Zope version is set to "Development/Unknown" in zopeversion.py. > > Though I think that it is not so serious problem, > we should update the tar ball or leave it? Leave it. If need be, we could release a 3.2.1.1 with the fix. If we replace it, people have no way of knowing whether the version they got has the fix or not, without peeking inside the tarball itself. This is a general release management principle: we have been guilty of violating it several times in tha past. Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEUkbJ+gerLs4ltQ4RAtHfAJ4jsQ7fkuBtcyhc7fHuAqmGKnNHmwCfQItd nyXvyLvuQslx88GhhudHm/I= =neWA -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: Google SoC Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > whit wrote: > >> Adam Groszer wrote: >> >>> I personally am tired of restarting z3 each time I made an error even >>> if it is just one char mistype. I'm doing now a wx based app, and the >>> problem is the same... made an error, restart, click 10 times... >>> It would be also a way to have a developer version which might run >>> slower. >>> >> >> amen... In the plone community, we have several influential >> developers who don't use z3 tech I suspect because developing with >> pythonscript is *still faster* than writing views and adapters because >> one doesn't have to reload to see minor code changes. >> >> also, in z2 land, refreshing a product loses all the related z3 >> registrations. >> >> being able to dynamically reload without restart would be a huge >> fricking win. > > > I guess we need to make this a priority for the next release. > > Python simply does not support a general robust reload, other than > restart. > > I think that there are 2 ways we can make progress in this area: > > - Speed up restart. I think there are a lot of ways that restarts > can be made faster: > > o Optimizae what we're doing now. I suspect that there are some > opportunuties here. > > o Load less. A Zope 3 application that only loads what it actually > uses will load much more quickly than a full Zope 3 checkout. > > The Zope 3 checkout has as much as it does to provide a > way to test a range of applications when we modify Zope 3. > We need to have a better way of solving this problem without > such a bloated checkout configuration. > > Also, we need to make progress with packaging, to make > it easier for people to get just the components they need. > I wanted to switch to eggs for the 3.3 release, but, sadly, > there wasn't enough time. I think switching to package-based > distributions and installation should be a top priority for > 3.4. > > Finally, there's a lot of interest in generating configuration > actions in Python, rather than ZCML. I suspect that avoiding > XML processing, conversion, and validation might speed startup > quite a bit. If we modified the validation to defer checking things like dotted name resolution until *after* all files have been parsed, then we could make it a requirement that configuration handlers have *no* side effects; at that point, we could save a pickle of the actions list, and restart by loading the pickle instead of parsing. We would need to "remember" things like file name and line number for the "dotted name" references, so that we could report them property in the "deferred" check (after all actions have run). > - Look at opprtunities for limited robust reload. Perhaps we could > define reloadable modules, especially for defining adapters, > with restrictions on their definitions and exports in a way > that allows robust reload. This would probably be based on the > persistent-module experiments. This is a fair bit of deep work > though and I'm not sure who has the interest and ability to make > it happen. > > I'm really not interested in a reload faclity, like the one commonly > used in Zope 2, that is not robust. I've wasted too many hours > helping people debug problems that were caused by reload misshaps. Amen. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEYLZ9+gerLs4ltQ4RApytAJ0fi8XBcnlt3aR5mM1L9MgdGSZ3DACgtGSj igZb17loQ69PYA8be5KR3jg= =CGBI -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: Google SoC Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: >>> The second approach is to reduce the ZCML processing time, which could >>>be integrated into the reload mechanism for Zope 2. This can be >>>accomplished by storing some binary representation of the ZCML, similarly >>>to ``*.pyc`` files in Python. Again there are several choices to consider >>>and they should probably all be tried. The first solution would be to >>>store a pickle of each parsed directive, namely the action and its >>>arguments. There would be one pickle file fore each ZCML file. When the >>>ZCML file changed, the pickle would be updated. Pickle loading would be >>>much faster than pure ZCML loading, since no XML-parsing, value >>>conversion and schema validation would be necessary. >> >>Note that this will require a refactoring of ZCML handlers to define >>picklable actions. This will also require refactoring so that work now >>done by handlers be defered to action execution. > > > As I explained to Jim on IRC, I am not proposing pickling the configuration > actions, but the configuration handler callable and its arguments. For > functions, this is trivial to do. For complex directives that use classes > this is a little bit harder, but not much. > > We will still have the benefit of saving value conversion and validation, as > well as XML parsing (though I am not sure whether pickle parsing is faster). > The approach is also much safer, since it does not depend on the subtleties > of directives, which is good. Not only are actions often unpickable, but some > directives also do not generate actions, but do their work directly; this is > due to some bootstrap issues. An approach pickling actions would miss > those registrations. The more I think about this, the more I believe > this is the right approach. - -1. This fact is a wart on the current system: it means that it is currently impossible to *parse* the ZCML file without allowing any directive make arbitrary changes to the interpreter state. Directives should *never* do more than register actions. We can remove all these issues that I know of if we make the dotted-name checker less "eager": rather than performing the check inline, during parsing, it should record the name, plus file and line number, for checking only after the actions have been run. At that point, all actions should be trivially picklable, and we get the bonus of being able to introspect the ZCML without actually executing it. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEZKJn+gerLs4ltQ4RAsq1AKCTKxCxvY2pGpMoDAOi5hVr3tz50QCeLyow kZneakUDzgu9jmo8IZXkME8= =UGZM -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: time schema field?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Rocky Burt wrote: > >>Hi all, >> >>I was just curious why zope.schema has fields for datetime.datetime, >>datetime.date, and datetime.timedelta but no field for datetime.time. I >>have a need for such a field right now and I think it'd be useful to be >>core to zope.schema rather than me create my own field. >> >>Would anyone mind if I added this to the zope3.3 branch and trunk? It'd >>be a very small thing. > > > +1 to the trunk > > >>Or perhaps I'm too late (feature-freeze) to add it to the zope3.3 >>branch? > > > -1 to 3.3 branch. Since we already have had a beta release, 3.3 should > be considered in feature-freeze. You could easily construe the omission of the 'time' field type as a bug; adding it is near zero-risk, as well. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEcdk2+gerLs4ltQ4RAu7wAJ9FIe41wF9Eyl8Mxwf1F1y9tq2bXQCdFfvk qAQOleo+ah5XRbSYk+5V1KY= =o5tC -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: SVN: Zope3/trunk/src/zope/exceptions/ Cosmetic bugfix for the exception formatter: it used to double the newlines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Gedminas wrote: > Log message for revision 68413: > Cosmetic bugfix for the exception formatter: it used to double the newlines > in exception messages (e.g. SyntaxError exceptions). > > Could this tiny little change be snuck into the upcoming 3.3 release? > Pretty > pretty please with sugar on top? +1. I'm not even sure why you're asking. ;) Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfd1y+gerLs4ltQ4RAoJZAKC9965Ee7i5KdKN1w7LhTKzpyzZ1gCeMFIt OQuS/2/IgZBGkExIx9NSlHw= =lRav -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: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > A small question/idea. > > When making svn:externals in Nuxeo, we always use https. That way > trees can still be checked out anonymously, but still modified. > > in Zope, threes are checked out with svn+ssh, but externals use svn. > That means that when you want to modify for example Five, you need to > delete the svn checkout and do an svn+ssh checkout instead. Also, if > you start changing things without remembering that you have to make a > fresh checkout, you have to svn diff it and them manually merge it > into the fresh checkout, and if you later do an "svn up", your changes > will be moved into a dead *.OLD directory (where you can't do svn diff > to extract your changes) and so on. > > The benefit of that is that you don't by mistake check in on a tag... > > My question is: Is there a good way of not having to check out a fresh > copy before you do changes? If not how would people feel about > switching to https or something instead? Especially if we merge the > trees, in which case both Zope2 and Zope3 will be made up mainly of > svn:externals... > - -1. The externals are just that, external to the Zope project. Modifying them should require extra thought, and a little extra effort, because the possibility exists that the change might break something outside the Zope tree. When we get to an egg-based Zope install, I think such a gesture would map onto "check out the source egg and force it into the path.' Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoB5L+gerLs4ltQ4RAqfRAKDUrcW7NYg4ljtHvYZto3H5hARV1gCglHWv 2pqpEsGwE1h6rckFpJgcmTo= =/cbq -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: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On 6/26/06, Tres Seaver <[EMAIL PROTECTED]> wrote: >> - -1. The externals are just that, external to the Zope project. > > Uhm. I have a hard time seeing Five and lib/python/zope as "external to > Zope". They are managed as separate projects, with their own priorities and releases. ZODB is the longest-running example of this "externality." >> When we get to an egg-based Zope install, I think such a gesture would >> map onto "check out the source egg and force it into the path.' > > Yeah, with eggs this issue might go away... Right. The 'svn:externals' will morph into dependencies, which will still be managed exterally to the dependent package. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoCer+gerLs4ltQ4RAqnwAKCVr5TeOU0XyLG/6drpaTJ65lGgiwCfbD74 V6ArZP8baL0Vo2fafxJQYOg= =fcxE -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: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitry Vasiliev wrote: > Benji York wrote: >> Philipp von Weitershausen wrote: >>> Dmitry Vasiliev wrote: >>> >>>> Log message for revision 68818: >>>> Fixed issue 525: DateWidget ru-format >> >>>> - type="text" value="2002-12-02 12:30:00" /> >>>> + type="text" value="2002 12 2 12:30:00 " /> >>>> >>>> Note that a EditForm can't make use of a get_rendered method. The >>>> get_rendered >>>> method does only set initial values. >> >>> Why does the display of the default DateTime widget change? > > DatetimeWidget now use zope.i18n for parse and format values so the > display is the same as for DatetimeDisplayWidget (note the line 1529 of > the form.txt). > >> ...and in such a strange way? > > It's the datetime format for the default locale, see the specification > in zope/i18n/locales/data/root.xml. > That breaks a test: File "/home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10/lib/python/zope/formlib/form.txt", line 1547, in form.txt Failed example: print MyAddForm(None, request)() # doctest: +NORMALIZE_WHITESPACE Expected: Got: not onlyt that, but I don't believe that '2002 12 2 12:30:00' is a valid date representation in *any* standard locale. The dashes-with-leading-zeros should be the default (it is the stock ISO date format). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoE23+gerLs4ltQ4RAj8JAJ0WzmZFOqNm1Fi2wRuOiGSIR3DwiACfXvEB BeY9EW5FqiOAAiRpXJlmWwo= =KV4D -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: zope.testbrowser too trigger-happy with urlencodes?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
> Hi,
>
> I've got a situation where a form submit will eventually end up in an
> action that does (in Zope 2):
>
> context.REQUEST.RESPONSE.redirect('/path/to/foo/#bar')
>
> This works fine through the web, but using zope.testbrowser, the # gets
> converted to %23 (which is the correct urlencoding of #). The url
> /pat/to/foo/%23bar is not valid, and I get a 404.
>
> I couldn't work out where this was being handled in zope.testbrowser, so
> and I guess it may be mechanize or some other library's fault, but I'd
> like to know if (a) it's a bug and (b) how I may work around it; save
> for that, I have one monster of a functional test now exercising a
> pretty complex set of forms and views - and a tutorial on how I did it :)
Note that the fragment identifier is *never* going to be passed to the
server by a "real" browser: instead, the browser strips of the fragment
part, submits the remainder of the URL to the server, and then does a
search for the appropriate '' element *on the client side*.
I'm not sure how this is pertinent to the problem you have found, but
Zope will never traverse '#bar' or '%23bar' in the real world.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEoHYj+gerLs4ltQ4RAmVbAJ0dvGvRS6/ayBbVyTXcJvR5ir0G5wCbBMEt
LyhGnkFCTbSztdHEGTF1dKM=
=iOB4
-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: What are zope.generic, z3c, ldapauth, et.al.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > > no problem, I agree to have a place for such infos. > The README.txt files are not good enough for give a overview > because you have to checkout first or browse the really slow > repos with a browser. > > Tell me where is somewhere and I can write something ;-) Maybe there should be a top-level README (a peer of the 'src' directory) which outlines the overall architecture and points to the individual sub-packages as they fit into that concept. Then, anybody who checks out the trunk, or a tag, or a branch, will get that overview in the "top" of their checkout. Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErcF/+gerLs4ltQ4RAh5gAKCD9ybcmAExAfrKFEYQu8qft8SwvQCfZWDc QvSFKo7PF7XXgP0fODhhgvw= =nqOe -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: The bug fixing problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > Hi, > > Marius Gedminas wrote: >> I do not think that the requirements to >> 4. Write unit tests >> 5. Merge bugfixes from trunk to the release branch >> 6. Wait for the incredibly slow updates on the collector >> >> discourage me all that much. > > Right. They don't discourage me either, but there is a special case in > 4) which I hit several times lately, where the unit tests need very > special effort. > >> I think that if more bug reports had a solution outlined in English, I'd >> be more likely to go fix them every now and them. > > Indeed! I would say that there are two bugs in the case you are describing: the one you meant to fix and the one which is the lack of any tests for the module / class / whatever. I would bet that spending your thirty minutes adding minimal tests to such a module is a *higher* value activity than fixing most bugs, because it makes it easier for you (or someone else) to fix that bug and others in that module. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErcLD+gerLs4ltQ4RAhSxAJ9xmfzyQILaq0/aVZr/ELlQOGu4dgCfQog8 YK2w5mPjtW7mAfpzFDYqS0Y= =m9Cv -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: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Zope 3, as releases is not affected by the security hole that > has plagued Zope 2, however, Michael Haubenwallner has pointed > out that some add-on-products, such as zwiki and bugtracker, may > provide TTW reST. They appear to be "safe" for the moment, but not because they intentionally disable file inclusion: rather, they have a bug (they set the 'encoding' to 'unicode', which then causes an exception). DTML Page was another possible culprit: it too is safe for the moment, because Z3's DTML does not have a handler for 'fmt="restructured-text"'. That is not really a comfort, because someday somebody is going to harmonize Zope2's DTML features into Zope3's DTML; at that point we are hosed again. > There are 2 issues here: > > 1. That we need to warn anyone using these that there is an issue, > including anyone who might be using a Zope 3 checkout in > production. > > 2. I want to move these out of the main subversion tree. > > For those of you on this list, consider yourself warned. > We should probably send out a warning more broadly though. > > Thoughts? I think the benefit of leaving file inclusion lying around in the main python path's version of docutils (for benefit of notional filesystem ResT users) is far outweighed by the risks associated with it. TTW ReST is *valuable* to people: it gets used by content authors, among others. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErsYB+gerLs4ltQ4RAjeCAKC20y9dt1CLJNzYH/QC3suafMdeoACfV1O7 C/2DHO5D+8hwacuMcvw8w5U= =qCze -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: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: > Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jim Fulton wrote: >> >>> Zope 3, as releases is not affected by the security hole that >>> has plagued Zope 2, however, Michael Haubenwallner has pointed >>> out that some add-on-products, such as zwiki and bugtracker, may >>> provide TTW reST. >> >> They appear to be "safe" for the moment, but not because they >> intentionally disable file inclusion: rather, they have a bug (they set >> the 'encoding' to 'unicode', which then causes an exception). >> > > Both restructuredText directives 'include' and 'raw' have an 'encoding' > option to set the name of text encoding of the external data file/raw > data (file or URL), it defaults to the document's encoding (if specified). > > .. include:: filename.ext > :encoding: utf-8 > > .. raw:: html > :file: filename.ext > :encoding: utf-8 > > should work as expected > > Michael Verified. Both wikis and bugtracker issues are capable of including arbitrary files using that spelling (in an instance created from today's Zope3 trunk, anyway). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErzS3+gerLs4ltQ4RAhboAKC0oxRwqZKBOiZxYEEPXoPi1NE0tACbBepr f5qWSi/OFDafP05XGXaOqxI= =x4ny -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: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: > Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Michael Haubenwallner wrote: >>> Tres Seaver wrote: >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>>> >>>> Jim Fulton wrote: >>>> >>>>> Zope 3, as releases is not affected by the security hole that >>>>> has plagued Zope 2, however, Michael Haubenwallner has pointed >>>>> out that some add-on-products, such as zwiki and bugtracker, may >>>>> provide TTW reST. >>>> They appear to be "safe" for the moment, but not because they >>>> intentionally disable file inclusion: rather, they have a bug (they >>>> set >>>> the 'encoding' to 'unicode', which then causes an exception). >>>> >>> Both restructuredText directives 'include' and 'raw' have an 'encoding' >>> option to set the name of text encoding of the external data file/raw >>> data (file or URL), it defaults to the document's encoding (if >>> specified). >>> >>> .. include:: filename.ext >>> :encoding: utf-8 >>> >>> .. raw:: html >>> :file: filename.ext >>> :encoding: utf-8 >>> >>> should work as expected >>> >>> Michael >> >> >> Verified. Both wikis and bugtracker issues are capable of including >> arbitrary files using that spelling (in an instance created from today's >> Zope3 trunk, anyway). >> >> > > Zope3 accesses docutils in a single point atm: > zope.app.renderer.rest.ReStructuredTextToHTMLRenderer.render() > > All objects created from the factory zope.source.rest are rendered here. > It should be possible to configure the docutils parser (and its > directives) by adjusting the 'settings_overrides' values. > > I think the same can be done (and is done already) for Zope2.x in > lib.python.reStructuredText.render() with the 'settings' dictionary. > > That way it would be possible to make the parser usage configurable and > no need to use a patched docutils. In Zope2 land, the module is still available, and can be used by other code (which may not know of that issue). I'm *not* in favor of shipping an un-patched docutils until we work this out. For instance, perhaps we should be patching docutils to make the *default* settings disable file inclusion and 'raw'; then the trusted code which wanted to render reST which legitimately needed those features could enable them explicitly. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEr6pm+gerLs4ltQ4RAhquAJ4yotGOLN5778NdQ5Fh2oO7wCRNIACfcZ3N //xqhLuWYrUAGEU5j8B214c= =CHum -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: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Alexander wrote: > Tres wrote: >> In Zope2 land, the module is still available, and can be used by other >> code (which may not know of that issue). I'm *not* in favor of shipping >> an un-patched docutils until we work this out. For instance, perhaps we >> should be patching docutils to make the *default* settings disable file >> inclusion and 'raw'; then the trusted code which wanted to render reST >> which legitimately needed those features could enable them explicitly. > > If we do this, it is important to communicate effectively with packagers > (like, in Linux distributions) that the Zope docutils is patched as a > workaround to this. > > This may be a problem for distributions that promise their users to do > bugfixes only, and are distributing a Zope that depends on the standard > docutils in their distribution. > > (I cc-ed Martin Pitt, who is responsible for Ubuntu security updates. > I'll fill him in on the rest of the discussion.) Packagers would have to do the moral equivalent of forking docutils in order to satisfy incompatible use cases: - Zope needs a docutils which is "safe at any speed" for TTW use. - Other Python applications may not need that safety, and may need the very features which Zope *must* disable. So forking docutils inside Zope is *not* evil, even when considering packaged versions, as long as the packagers know about the fork, right? Hoping-we-are-in-violent-agreement'ly, Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsAu3+gerLs4ltQ4RAkq5AKCO6w1PxQbt9QyOffRY//6Be0QlSwCgpMaT 1XxvUjzUhUBlr5uTk44u6B8= =9qal -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: Version control of ZOPE3 objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pjotr Prins wrote: > Hi, > > I need to build a versioning module for the xParrot project > (http://xparrot.thebird.nl/). I have some questions and wondered who > would be inclined to help with the architecture phase. > > The idea is to save objects that implement IVersioning on a > modification event to either ZODB, or to an external version control > system like subversion. The latter would be nice as it could handle > for example diffs through Websvn (a reverse proxy may be needed to > handle access control through ZOPE). > > Using an existing version system saves a lot of code and would allow > for functionality like branching etc. On the other hand commits have > to be run on a separate thread (which I can model on the current > mailqueue implementation). Also deployment would require extra > system administrator skills. > > Before I go down this route I would like to ask if anyone has a > better idea? And who would take an interest in this little project, > and doesn't mind bouncing off a few ideas? Integration with a non-transactional backend (such as Subversion)is going to be tricky: the mailqueue, for instance, manages to avoid re-sending mails for requests which are repeated due to ConflictErrors, but it can't cope with failure in the actual mail handoff. In the case of a subversion sandbox, you are going to need some kind of notification mechanism, at least if each appserver has its own sandbox, so that you know when to do 'svn up' due to a modification in another appserver. You are also going to have to serialize access to the sanbox between threads in a single appserver. If a commit fails (e.g., due to a conflict error), it is going to be tricky for your application to handle: assuming that you have delayed doing the actual 'svn commit' to the end of the request (in 'tpc_finish', most likely), then you won't be able to abort the Zope transaction. You will also have to come up with UI to allow the user whose commit failed to resolve the SVN-level conflicts. I don't know what kind of format xparrot uses for its documents. Is it going to be diff-friendly? If not, then most of the win for SVN is going to go away. At that point, I would be considering some kind of ZODB-based solution, either a content repository (I've done this for large media sites) or else making the documents themselves into containers for revisions and drafts (I've done that as well for systems with fewer, but more complex, documents). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsXA2+gerLs4ltQ4RAibxAJ45d4FazCsr30X4qUHDveANoT992ACfU5/w Vj8UWQYq+KvC0Yeh+80rd40= =KaYo -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: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: >> So forking docutils inside Zope is *not* evil, even when considering >> packaged versions, as long as the packagers know about the fork, right? > > The unforked docutils provides the necessary safety when used correctly. > It is our careless use of the feature that was the cause of the problem. > As Florent pointed out, long experience with text processing systems on Unix (Tex, postscript, etc.) says that enabling file inclusion by default is a security hole. Leaving it enabled by default makes docutils at least partly to blame for such holes (under a doctricne of "attractive nuisance"). If, OTOH, the downstream programmer had to explicitly enable the risky behavior, then any breach would be *that programmer's* fault. Relevant history: - SVN says that the knobs to disable the dangerous features, along with the docs for the why teh features are dangerous, were added fifteen months ago: http://svn.berlios.de/viewcvs/docutils?rev=3071&view=rev - Those knobs were made available in the 0.3.9 release of docutils (per the HISTORY.txt file). - Andreas upgraded Zope to that release last October, just before initial hotfix (from the timing, on 2005/10/09, it looks as though the hotfix have been the motivation for the upgrade). - Because of the way we ship docutils (there was a lot of wrangle about this, as well, with Andreas moving stuff around to suit the course of the wrangle) we don't even ship the documents which label those directives as 'dangeroous' (they are off in the 'test' subtree). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsf7j+gerLs4ltQ4RAgUiAJ4kntQ8aOogx6gC+r3TmlEO+Bhs5QCgssm6 co2YkpdSgWiv+pWfEPkyo9w= =nvkT -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: SVN weirdness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: > Benji York wrote: > [craziness] > > That'll teach me to reply to email before coffee. Philipp explained the > observed behavior. And another argument for usning tags instead of 'branch + revision' for externals: if SVN doesn't remember that the external should be "frozen" to the revision it was checked out with, then SVN is broken here. /me *still* wants a 'svn ln' command which creates a read-only "tag" from the combination of branch and revision, but the SVN team is uninterested in supporting release managers' use cases, it seems. Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2z8e+gerLs4ltQ4RAo2aAKC0/zB6diIGdL3zYnH8aMsRLDQtOwCbBGvj HUzLmtA/Jf4NVr2jDa51ETo= =JIgW -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: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Stephan Richter wrote: >> On Wednesday 16 August 2006 09:42, Martijn Faassen wrote: >>> Anyway, nothing is said about dependency on GPL-ed code. That's a >>> different debate. It's strictly not against rules, but it does mean one >>> expectation is broken: one might want to expect that all code in the >>> repository is freely usable without having to worry about >>> GPL-provisions. This is not the case for code that depends on GPL-ed >>> code. Even though this may be already a grey area for other reasons, it >>> still makes sense to think about the intent and people's expectations >>> when checking in a codebase. >> >> My expectation is that I have to read all included license files and >> the licenses of the dependencies. > > If the GPL is one of those included licenses, the whole package falls > under the provisions of the GPL, not just the dependencies. This is what > the GPL requires. I'd prefer to have somebody at the foundation pay for advice on this: I have consulted to one very Zope-and-Python savvy IP lawyer (Ron Chichester) who has subsequently made his analysis of the interaction of GPL and Python's import public (at the Plone Symposium in New Orleans last March). He noted first that the GPL cannot restrict more than what copyright law permits, which is why "mere aggregation" of GPL and non-GPL software does not trigger the GPL. He then dissected the process of importing one Python module from another, in terms of the actual operations (including copies made in RAM) which take place, and argued from this analysis that the GPL does not govern a program / module which merely imports code from a GPL'ed module. I bring this up not to argue for Ron'd analysis, but only to say that assuming that you know what the GPL means in the context of Python might need to wait until the issue has been adjudicated. In the meanwhile, it is probably *not* going to be within the ZF's IP policy to allow checking in code which forces users of the repostiory to deal with the GPL at all; I would consider such a checkin now, in the interregnum period, to be particularly ill-advised. >> Remember, we are talking only about a dependency here, not even an >> inclusion. This case is much weaker than a lot of others. > > I know we're talking about a dependency here. I'm not saying what you > did was wrong, but I do also think Benji brought up a good point that > should be carefully considered. The Zope repository as managed by ZC has had a clear anti-GPL policy; I don't think that the foundation's policy is likely to be more favorable to code which might, in theory, trigger the provisions of the GPL. The appropriate thing here would be to remove the code which depends on the GPL, and then ask the foundation's permission before readding it. In the meanwhile, codespeak.net might provide a reasonable place from which to continue development of said code. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4/qQ+gerLs4ltQ4RAsNFAJ0eYNbPL7ryaHvqSHELI5ZUqG95KgCeMGBs R3Sv0rbyHDEAXXRgWTPkc/A= =Aieu -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: SVN: Zope3/branches/3.3/ Fix issue 383.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Xicluna wrote: > Log message for revision 69521: > Fix issue 383. > Patch on zope.app.server was missing on zope.app.twisted (see rev.30448). Thanks very much for carrying this forward! > Changed: > U Zope3/branches/3.3/doc/CHANGES.txt > U Zope3/branches/3.3/src/zope/app/twisted/schema.xml > U Zope3/branches/3.3/zopeskel/etc/zope.conf.in > > -=- > Modified: Zope3/branches/3.3/doc/CHANGES.txt > === > --- Zope3/branches/3.3/doc/CHANGES.txt2006-08-15 20:02:00 UTC (rev > 69520) > +++ Zope3/branches/3.3/doc/CHANGES.txt2006-08-15 20:02:22 UTC (rev > 69521) > @@ -10,11 +10,10 @@ > > Bugfixes > > - - Fixed issue 383: Change default configuration in zope.conf to > -bind explicitely HTTP server to 127.0.0.1 and give information > -how to bind to any network interfaces. > -Note: if you omit to specify host or ip address, there's still > -a discrepancy between Windows and other platforms. > + - Fixed issue 383: Twisted and ZServer work the same on any platform. > +Default configuration is to bind servers to all interfaces. > +You find additional information in 'zope.conf' to know > +how to bind to a specific address. > >- Fixed issue 574: Page template traversal adapters were not correctly > proxied. > > Modified: Zope3/branches/3.3/src/zope/app/twisted/schema.xml > === > --- Zope3/branches/3.3/src/zope/app/twisted/schema.xml2006-08-15 > 20:02:00 UTC (rev 69520) > +++ Zope3/branches/3.3/src/zope/app/twisted/schema.xml2006-08-15 > 20:02:22 UTC (rev 69521) > @@ -4,7 +4,7 @@ > > datatype="zope.app.twisted.server.ServerFactory"> > > - > + > > > > > Modified: Zope3/branches/3.3/zopeskel/etc/zope.conf.in > === > --- Zope3/branches/3.3/zopeskel/etc/zope.conf.in 2006-08-15 20:02:00 UTC > (rev 69520) > +++ Zope3/branches/3.3/zopeskel/etc/zope.conf.in 2006-08-15 20:02:22 UTC > (rev 69521) > @@ -17,16 +17,14 @@ > > # Standard HTTP server for Zope 3. > # > -# HTTP server is explicitely bound to local loopback. > -# You can keep this configuration if your server > -# stays behind a dedicated web server. > -# Alternatively, you can change address to 0.0.0.0:8080, > -# if you need to bind to all network interfaces. > -# > +# HTTP server is bound to all interfaces. > +# You can bind to any IP address or hostname, > +# or use 127.0.0.1:8080 for local loopback. > # Server: All Servers > +# > >type HTTP > - address 127.0.0.1:8080 > + address 8080 > > > # Ready to go HTTPS server. You just need to make sure OpenSSL is installed. > @@ -69,7 +67,7 @@ > path $DATADIR/Data.fs > > > -# uncomment this if you want to connect to a local ZEO server > +# Uncomment this if you want to connect to a local ZEO server > # instead: > # > #server localhost:8100 Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4/vY+gerLs4ltQ4RAv85AKCFOnFtce9aMIdIdFtCtl14ngyMzgCfaJbv EIBuX6RSu9XaL2/YuECeRas= =asJ7 -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: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: > --On 17. August 2006 01:11:44 -0400 Tres Seaver <[EMAIL PROTECTED]> > wrote: >> >> The appropriate thing here would be to remove the code which depends on >> the GPL, and then ask the foundation's permission before readding it. >> In the meanwhile, codespeak.net might provide a reasonable place from >> which to continue development of said code. > > That's extremly odd. Consider the following case: I am writing a ZPLed > Zope product but include some migration shell scripts that call some > common GPLed unix programs for a particular task...I wouldn't be allowed > to checkin this > software on svn.zope.org? The advice to move the code out of the > repository is not really legitimate. Neither rules as given through the > contributor agreement nor unspoken rules were violated. Once again: > using GPLed software does not make your own ZPLed software automatically > GPLed. Some folks (many of those who release Python software under the GPL) believe that 'from foo import bar' triggers the provisions of the GPL, arguing by similarity with the somewhat-equivalent operation which occurs when including / linking code in a C / C++ application. These same folks would *not* argue that invoking a separately-compiled GPL application, and then consuming its output (or relying on its side effects) triggers the GPL on the invoking application. In the realm of copyright law, such authors' "intent" about the use of their code might actually be pertinent if the issue is ever tried in court. In the meanwhile, the code in question exposes others beyond the author (those who incorporate the ZPL-but-dependent-on-a-GPL-module code in their own applications) to a risk of being the guinea pig who gets to pay to prove the point in court. I consider such needle^h^h^h^h^h^hrisk sharing to be inappropriate within the Zope repository. I say this as a Zope developer / ZF member, who is *not* a ZF board member; the foundation's IP policy is more easily construed to support such a position, as well. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE5Abx+gerLs4ltQ4RAu28AJ43Z0E7Qmu5fAEoebtY/tvcx0S0fgCgitCf l8H27Qu3bxh6gMuuxn5RDy8= =0cMb -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: Testbrowser failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: > > > --On 19. August 2006 17:25:39 +0530 Baiju M <[EMAIL PROTECTED]> wrote: > >>> >> >> This is already fixed according to: >> http://www.zope.org/Collectors/Zope3-dev/645 >> >> The fix is in 'ClientForm.py', this file is *not* set as an >> svn:external in Zope 2. >> Just setting this as svn:external to Zope 3.3 will fix this problem, >> otherwise update this module. >> > > Thanks, I copied over the file. Unfortunately svn:externals don't work > on files but only on directories. Maybe make it a package, 'lib/pythong/ClientForm', with the current module code in its '__init__.py'. 'lib/python' shoulc not carry around such "forks", if we can help it; better svn:externals today, eggs tomorrow! Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE5zEQ+gerLs4ltQ4RAsx9AKCD/Fh992o5V26tutPc2ul6+vl0JwCgig6V fOQgEYX4PVHVUFmTXx7PSy8= =RPIT -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: Zope 2 clock server for Zope 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > Florian Lindner wrote: >> Am Sonntag, 20. August 2006 06:11 schrieb Christian Theune: >>> Hi, >>> >>> you might try a look at the recently released zc.async which allows you >>> to leverage twisted asynchronous handling together with persistent >>> objects (as far as I know right now, haven't looked at it personally >>> yet). >> >> I've overflown the readme and it looks rather complicated compared >> with the Zope2 clock server which is pretty straightforward. > > Well, it's not exactly the same use case and it's more generic AFAIU. *And* more complex, *and* it requires that you run Twisted. ClockServer is dirt simple, robuts, and runs inside ZServer. It doesn't try to be anything more than a way to trigger periodic requests. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6ciA+gerLs4ltQ4RAi47AJ4k9dlT7r1pFzt39BsksKSMLOjB1QCfRY+E xj7ylKpyTHfBfaIFgpx3Djc= =5OaD -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: proposal: error reporting unification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Martijn Faassen wrote: >> Hi there, >> >> See the following proposal: >> >> http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ErrorReportingUnification > > +1, as posted in a comment already. > >> To be determined is whether we want to keep the rules currently in place >> for the SiteError log and apply them to the error reporting utility as >> well, or remove them for the SiteError log as well. I'd propose the >> latter - it's evidently not an issue that all errors are reported in the >> utility, so why suppress them in the logging? > > I'd be fine with that, but we'd still need to filter UserErrors, > NotFound, etc. logged. > > UserError is thrown by a piece of software when it wants to know the > user of the application about it (e.g. invalid container names). Such > errors aren't of interest for the system error log, at least not > normally. Zope2's experience argues otherwise. Having a log of the error allows the developer to investigate an error reported by the user, even though the user can't give enough information to allow reproduction. *I* want to be able to push such errors to the log; *you* might never need to. Ergo, it is policy, and needs to be managed as such. > NotFound errors would occur every time IE tries to find > favicon.ico, so again, not very useful... That is more policy, though, and should be settable on the error log. Sometimes getting the log of the NotFound is *important* in some cases, even though it is useless most of the time. This is an anti-case for "emergent" behavior configured by adapters, IMHO; better to configure the "service" (the error log object, or its global equivalent) to handle such choices. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE7dVS+gerLs4ltQ4RAuWnAKCzV+mBwgsxgR6xNPruVpGSqlmnzwCcDZGP EBUNFtmy60W2C67jK3oBFgI= =Rtwg -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: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > Hi, > > this is a rant. I don't want to be destructive or disruptive, but I feel > like I need to turn this up right now. > > Let's start with something positive: I love Zope 3. I do. I know it > almost since the beginning and I see how it works out. > > But to be honest, I too often get the feeling that something in the > process is wrong and we are failing to acknowledge it or work on it. > > I think we make it way to hard for people who want to use Zope 3 as > developers making applications with Zope 3. > > Why? Because we keep changing stuff and don't tell people in VERY LARGE > LETTERS about it. > > What worries me most is that I, although I'm contributing to Zope 3 > every now and then, even fall into this quite often and I'm getting > tired of it. > > I can't read every proposal or every commit message or every post on the > mailing list. I try to, but I can't. And I think that normal developers > shouldn't have to try to. > > When Philipp explained the zope.component thing in an earlier post I got > annoyed again because I was relying on information that obviously was > false. That's probably my fault because I didn't digg deep enough to > verify the truth whether zope.component.provideUtility works against the > thread local component registry or not. When I saw that > zope.*app*.component does that I got scared because it's so similar and > maybe hard to distinguish. > > What I'm worried about is that we have to come up with a *MUCH* better > way to tell people "What is *the single* way to do this or that?" and > "Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!". > > Again, maybe I'm only hitting this all the time because I'm living most > of my live on pre-release-branches or the trunk, but still. > > I think if Zope 3 shall be used by many people, this is a major obstacle. > > I hope I don't annoy anybody, but I had to get that off my mind. Insulating non-core developers from this kind of churn is what the "façade" module 'zapi' was orignally for. Folks who were writing application code would have a reliable location in which to find the "public" API, and would not be exposed to the deprecation dance caused by tree refactorings: instead, the person who did the tree refactoring would just adjust the 'zapi' imports, and everyone else's code would Just Work (tm). That module would also be the logical place for lots of the BBB code now scattered around the tree. I'm OK with having "in-tree" code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that "janitorial deprecation" is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the "better" name. The ongoing cost of that deprecation is then borne by everyone else. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE+blG+gerLs4ltQ4RAhEEAJ9/CLYNqlrPFWh+3UnPwaraMMLs7QCfVYYp 1fiertpiMU2/pFhAe6ovbQk= =esi5 -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: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: > Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: >> ... >> I for one prefer exceptions over manual error handling. And I prefer >> straight-forward APIs over unnecessarily complicated constructs. > > But you probably would not prefer if these "straight-forward APIs" > were continously changing. > I prefer a slightly suboptimal stable API over one that is > optimized in each version in a non backward compatible way. > > > I do not want to say that this is happening in Zope3 land. > I do not yet use Zope3 in earnest and see what is happening > more from the mailing list than from my own experience. > >>> So, for me, it would be great if developers would take more time to >>> weigh up the "what does this new feature or refactoring bring" against >>> the "how much of a PITA is it going to be for everyone else to relearn >>> this"... > > I like new features but often could not see the gain of refactorings. > Many refactorings in Zope 2 land were just silly, e.g. whitespace > refactoring such as: > > from X.Y.Z import a, b, c > > refactored to > > from X.Y.Z import a > from X.Y.Z import b > from X.Y.Z import c I might be the perpetrator, but surely such a change has no impact on code which imports the module. Does this affect you because it breaks patches you maintain? > I do see the gain of moving out general purpose functions from > "zope.app" into "zope". But, I would do it in a backward > compatible way -- even when "zope.app" then contains quite > a few trivial packages redirecting to the relocated packages. As I said earlier, I actually *like* the insulation provided by a "façade" package: it leaves the "internal" location free to change wildly, without propagating the churn from that change out to those who are clients of the code. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/HSr+gerLs4ltQ4RAiLGAJ490R2aiQAAeuVELa90QzjLNYszxwCfa4Bq ccve4CXAHlKBRgoTl+FVYuY= =BPQx -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: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Tuesday 05 September 2006 07:39, Marcus J. Ertl wrote: >> And I realy don't know, what I would think, if I had Zope3 in use on a >> productiv system? Schould I really change all packages each half a >> year to reflect changes in Zope3? > > That's what we do. In fact, I am not even using releases. As soon as a change > happens in the trunk, I migrate the code base I am working on and schedule > updates for the other code I have. And if you do that, then life is not that > bad. In my opinion it is more difficult to upgrade between major releases. That is a damning indictment of our process, if so. We should be managing our release process such that the "normal" path is straightforward (trivial upgrades between third dot releases to fix bugs, well-documented upgrades between second-dot releases at well-planned intervals to take advantage of new features). We should make this so even at the cost of making life harder on the core developers. Unless, of course, we don't expect anyone but the core developers ever to run Zope3 in production environments (which is very nearly the case today). Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/bQM+gerLs4ltQ4RAuc8AJwLhm/0O31jj+YzulX3hvJ5+gd7KQCglanD tf48bDO+aNHYf6gmcSewwK8= =BvhO -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: Zope 3.2 maintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Friday 08 September 2006 04:12, yuppie wrote: >> Are there good reasons why these changes were not backported? >> >> I volunteer to backport some fixes I'm missing in Zope 3.2, but that's >> no general solution for keeping the current stable branch maintained. > > The short answer is: We are a bit sloppy. I always develop against the trunk, > so when I fix an issue, I do not event think about porting it back to another > release, other when one is imminent, like Zope 3.3 now. I think most other > Zope 3 developers are the same. I consider this practice unacceptable for work on an allegedly ready-for-production package. The Zope Development Process document [1] states: When you check in a bug fix, you almost always need to: * Check in the fix on the current release branch * Note the fix in the /doc/CHANGES.txt on the current release branch * Merge the fix to the trunk to be sure its fixed for the next feature release Only "feature work" should be done primarily on the trunk. [1] http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAbKx+gerLs4ltQ4RAt6SAJ9fYC0322cIzW0NeHMe+EGT+RSqsgCdHH7T t2Um2o27+28g6mMLDZiI5XU= =l+RS -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: [Zope3-dev] Re: Zope 3.2 maintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Jim Fulton wrote: >> I agree in principle. In practice, I'm not sure we have enough >> maintainers to get a release out, let alone maintain two previous >> release branches. :( We need more volunteers. The marginal effort to do the bugfix correctly (i.e., first on the release branch, then forward-porting to any beta branch and the trunk) is not that big. If we can't get our volunteers to do that, then maybe we need to quit pretending that Zope3 is or ever will be "production ready." Without such a practice (which Zope2 has had since before community checkins), how can we expect anybody to take Zope3 seriously? >> If we want to maintain releases for a year, I suspect we need to >> release once a year. Backporting a fix from the current release branch (3.2, in the current case, since we still haven't released 3.3) to older release branches is more iffy to me: I would say that we should only mandate that bugfixers consider it for "critical" or security-related bugs: they may, if they wish, backport, other fixes, but we make no committment that there will ever be a subsequent release from that branch. > I did Zope 3.2.1 mostly because some formlib fixes were needed in Zope > 2.9. I'm prepared to do more Zope 3.2.x releases as they are necessary. > People just need to backport their fixes. > > That they haven't done this is also partially the fault of the "checkin > police" (which I count myself a member of ;)). I'll be more attentive in > the future. I'm prepared to do this mercilessly (also for older > bugfixes), the question is whether we shall adopt this policy now or not. I'm already on record in favor. ;) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBYC2+gerLs4ltQ4RAsZrAJ9Z1DuhIZcQu5KYQkelEhY/NiAHKQCeLE33 65TECNNtZ9wbEb5EjK6hzio= =S6f6 -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: Zope 3.2 maintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: > On Mon, 2006-11-09 at 11:28 -0400, Tres Seaver wrote: >> Philipp von Weitershausen wrote: >>> Jim Fulton wrote: >>>> I agree in principle. In practice, I'm not sure we have enough >>>> maintainers to get a release out, let alone maintain two previous >>>> release branches. :( We need more volunteers. >> The marginal effort to do the bugfix correctly (i.e., first on the >> release branch, then forward-porting to any beta branch and the trunk) >> is not that big. If we can't get our volunteers to do that, then maybe >> we need to quit pretending that Zope3 is or ever will be "production >> ready." Without such a practice (which Zope2 has had since before >> community checkins), how can we expect anybody to take Zope3 seriously? > > I've only ever worked on one open source project where I was not > supposed to backport my fixes to the maintenance release branches and > that is Plone. For Plone we have someone responsible for back-portting > that stuff in bulk. It makes his job harder if we manually back-port > fixes as then he has to be more selective with the patches he backports. > > Thanks Hanno! That is an enormous amount of effort: major kudos to him for being willing to tackle it. I think that in some cases, such a practice will not necessarily going to give the highest-quality result: the "backporter" won't always have as much context about the bug as the original "fixer", and may not be able to ensure that it is fixed properly. > But my point is it is pretty standard behaviour to have to backport > fixes to all actively maintained branches. I'm actually arguing against calling it "backporting" at all: the point is that it is *more* urgent to fix the bug on a release branch than to do so on the trunk, so we should refer to the process as "forward-porting". Pragmatically, it is typically *easier* to forward-port a bugfix than to backport it, because the "common ancestry" in the merge is more likely to be helpful. Of course, some kinds "janitorial" practices (e.g., tidying up whitespace, imports, etc.) can make this harder if done only on the trunk. That sort of friction is one of the reasons why change velocity drops off on successful projects. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBYYJ+gerLs4ltQ4RAl/fAJ474wC5H+0i15e/YPgmDqXb5h4GzQCgw9x0 IZ44jkt1FOtuHMV+3v6AUF4= =+SWn -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: The bug fixing problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Gerken wrote: > On 7/16/06, Jim Fulton <[EMAIL PROTECTED]> wrote: >> >> On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote: >> >> > On 7/7/06, Julien Anguenot <[EMAIL PROTECTED]> wrote: >> ... >> >> > I marked the bug as bug + bugfix but nobody cares. That is much more >> > discouraging than what I can not do nice wiki links to in my bugreport >> > other bugtracker items or svn sources like it is possible in trac >> > itself. >> >> What is the issue number you are referring to? >> >> I don't see any bug+solution issues that seem to be from you. >> Perhaps you submitted 572? Or perhaps your issue was resolved. > > Sorry for the very late answer, but our employee put us into a tourist > place with no internet access, and before I sent the link I wanted to > ensure that the tests still work. > This is the issue: > http://www.zope.org/Collectors/Zope/1944 > But the original issue is just, that it turns one off, to see no > response, of course I'm giving a bad example in responding so late. I'll note that one developer (Andreas) did try to merge the patch, and then ended up backing it out because it broke tests. I'm also not quite sure I understood the rationale for the patch, when reading it, which makes it harder for me to just jump in and merge it. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBYac+gerLs4ltQ4RAkS4AKCf1BMG2VlNwuu0jyUUKYhWEMkAuwCdFsjS /elBt9ucMltYtr2w7PvKL8c= =uW61 -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: Working on the 3.3.0rc1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TAHARA Yusei wrote: > Hi. > > At Tue, 12 Sep 2006 17:43:27 +0200, > Christian Theune wrote: >> Then this is a small reminder to Yusei, that the 3.3 branch has been >> tagged for RC candidate and only *very critical* changes are allowed to >> go there until we do the release. > > Oups, Sorry I missed the announcement. > I'll be more careful in the future. You didn't miss it: the announcement of the freeze came out about 15 minutes after your last checkin on the 3.3 branch. Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBxyp+gerLs4ltQ4RAnwxAJsEtK3uFfS9/U09R0d7Jj+2l79H/gCgopZ4 guoewgIgKoQUpb9iJSokokw= =di8m -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: Default zope.conf DB setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Saturday 16 September 2006 05:10, Philipp von Weitershausen wrote: >>> *If* someone else had that problem too, I'd propose to change away from >>> the fallback of using zope.conf.in (we force people to create the >>> principals too, don't we?) >> Right. I wouldn't mind that. +0 from me. +1 from me: '*.in' should *never* be read by default. > It is all about being quick to get started. I like that; so -1 from me, but I > do not feel strongly about the issue. If we did a 'make install' or 'make instance', that step could do the copying automatically. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFDChO+gerLs4ltQ4RAjueAKCSJLRQeUo21NziWYh+cQ3h0QkBEACfZRvt ZXtVko7LySa1QdTPqXVl4Iw= =RLx9 -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: Naming tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Monday 18 September 2006 07:13, Jim Fulton wrote: >>> but not both and not mixed for the same version. My personal >>> preference is 'rc'. >> My preference is c1. > > Me too, because then you have a, b, c. :-) +1 for 'c1', because it fits the way other Python packages are numbered, and how setuptools interprets the value. Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFDt9A+gerLs4ltQ4RAvI4AKCOMs9QikAfEoLCHBskhnhsYwqUIACgiOfJ EgcSrvC8vA5mkaJy+WCV+Fw= =8Yyr -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: zc.selenium, Selenium 0.7.1 bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > Hi all, > > The zc.selenium package includes Selenium 0.7.1 (the latest release), > which includes this unresolved issue: > >http://jira.openqa.org/browse/SRC-99 Selenium just released version 0.8 for the "Core" portion last night; it doesn't appear that they have fixed that bug: http://www.openqa.org/selenium-core/release-notes.html http://jira.openqa.org/ReleaseNote.jspa?projectId=10030&styleName=Html&version=10271 > This impacts one of our projects, and the workaround described avoids > the problem. It's not clear that the workaround is more than that (or > that it's not). Is anyone else affected by this? Does the workaround > have a negative impact for anyone? > > I've attached a patch against zc.selenium that implements the > workaround. I'd like to commit this in zc.selenium if there are no > objections. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFEbFq+gerLs4ltQ4RAh4OAKCPRwVqQUP+KAQvg/5uQ7j9qG/cUQCgoSAH 56KXafPxffhLfNihT6OZDZY= =1xcS -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: zcml questions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Chris Withers wrote:
>> Philipp von Weitershausen wrote:
>>> AFAIK, getUtilitiesFor is not supposed to order these in any way.
>>> While the returned iterator does find them in a reproduceable order
>>> due to the implementation, you shouldn't rely on that.
>> OK, so you should always sort this list when using it for a UI?
>
> If you explicitly want the list to be sorted, sure. The question is how
> you want it to be sorted. Perhaps not everyone wants it to be sorted by
> the utility name.
>
> Also, getUtilitiesFor is a generator. That makes it efficient if you
> just get a few utilities, realize you have the one you want and don't
> get the rest. If you expect a sorted output, you lose that efficiency.
>
>> Hmm, seems odd, is getUtilitiesFor used for anything other than
>> generating UI's?
>
> I can't say off of the top of my head. Why don't you grep :)
>
>>>> Also, if a site administrator wanted to "unregister" one of these in
>>>> site.zcml, maybe because they didn't want the Traverse executor to be
>>>> available, how would they go about doing that?
>>> ZCML has no way of unregistering specific utilities or adapters
>>> (though there's a Python API).
>> That sucks :-(
>>
>> I thought the whole point of ZCML was that a site manager could override
>> setup in site.zcml. 50% of that aim isn't done if they can't turn stuff
>> off as well as on...
>
> Right. I think zcml:condition was a first step into that direction. Its
> implementation was very use case-driven. It seems you have a use case
> for more control over ZCML, so it'd be nice to hear from suggestions how
> you would envision a directive disabling feature in ZCML.
>
>> Where can the python api for unregistration be found?
>
> On site managers. They have unregister* methods. So, *after* your ZCML
> has been loaded, you could poke at the global site manager and
> unregister the utilities that ZCML registered.
>
>>> In ZCML we typically define "features" and apply a condition using the
>>> feature:
>> Why? So you can have yet another (pointless in this case) layer of
>> indirection?!
>
> *sigh*
>
> We use it quite well in Zope 3 to enable/disable development tools like
> APIDoc. We have a feature called 'devmode' so all debugging tools can
> hook into that. APIDoc itself also enables a feature when it is loaded
> so you can register things with APIDoc, but only if APIDoc is available.
>
> zcml:condition also has another verb, "installed", that allows you to
> load directives only when a certian Python package is available, e.g.:
>
> package="worldcookery.pdf" />
>
>>>
>>>
>>> >> zcml:condition="have twiddler.defaulttraverser" />
>> This is missing the point. There are an array of inputs, outputs and
>> traversers available. There's a sensible default set registered, but
>> site managers might have different requirements which are likely to
>> include disabling some of the default registrations.
>
> Why woudl they have to disable existing ones? Can't they just choose
> different ones, leaving the default ones sitting there?
>
>> How should I do things such that they can do that?
>
> I'm just wondering whether you really need the disabling feature.
I've wanted it. My major beef with the way we are *using* ZCML now is
that we expect package authors to provide policy-laden configuration for
their packages ("sensible defaults") but provide no means for the admin
to reuse that configuration selectively; their only realy choice is to
*copy* the configuration and edit it.
I argued *long* ago (after the first ZC-internal Zope3 sprint, I think)
that the '' directive should be allowed to be complex, with
subelements like '' or '' to pull in specific directives.
Such a practice would require either that we have XPath support
available, or else that we come up with a way to mark the directives
(e.g., a 'zcml:id' attribute). It would *also* require that we
implement the "no side-effects during parsing" policy (my other favorite
"dead horse" in arguments about ZCML's implementation / usage).
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFEpBV+gerLs4ltQ4RAlldAJ9FwPgZV3NCE16wXiZGwpljrpZfswCeLwU5
PdZXr3WyOcBeEpcAzEe2QEg=
=XbgN
-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: zcml questions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>>>> How should I do things such that they can do that?
>>> I'm just wondering whether you really need the disabling feature.
>>
>> I've wanted it.
>
> Okay :).
>
>> My major beef with the way we are *using* ZCML now is
>> that we expect package authors to provide policy-laden configuration for
>> their packages ("sensible defaults") but provide no means for the admin
>> to reuse that configuration selectively; their only realy choice is to
>> *copy* the configuration and edit it.
>
> True.
>
>> I argued *long* ago (after the first ZC-internal Zope3 sprint, I think)
>> that the '' directive should be allowed to be complex, with
>> subelements like '' or '' to pull in specific directives.
>> Such a practice would require either that we have XPath support
>> available, or else that we come up with a way to mark the directives
>> (e.g., a 'zcml:id' attribute).
>
> Well, we already sort of that this marking with "features" +
> zcml:condition. But and could be more powerful wrt
> packages, modules, or even classes and interfaces.
>
>> It would *also* require that we
>> implement the "no side-effects during parsing" policy (my other favorite
>> "dead horse" in arguments about ZCML's implementation / usage).
>
> Yup. I think there are very little side effects currently. I can't think
> of one off of the top of my head, to be honest (but I'm sure there are).
We do "eager" checking of dotted names (during the parse), which makes
it impossible to write a directive which synthesisizes the target of a
dotted name without side-effects (e.g., the 'five:bridge' directive).
If we delayed the check until after parsing was complete, then we could
eliminate one source of side effects. Side-effect-free parsing would
open a lot of possibilities: "ZCML introspector" tools, for instance.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFEpeX+gerLs4ltQ4RApuDAJ9GW+vIzSOzCQ7vj6iUBpmkh5LeFwCcC29l
V2u8kqNL/VJKTXOEPc1Ryl0=
=gIbE
-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: the maintenance of change logs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
>
> On Sep 22, 2006, at 11:47 AM, Martijn Faassen wrote:
>
>> Hi there,
>>
>> I am about to do a new egg release of zc.catalog and will be putting
>> out other eggs as well (to the cheeseshop as we now have our own
>> category there).
>>
>> I notice in the SVN that there have been quite a few changes to
>> zc.catalog. We do not have any CHANGES.txt or such, so it's very hard
>> for me to determine what in fact changed without digging through SVN
>> commit messages and such.
>>
>> So, I propose we start maintaining CHANGES.txt in packages, and mark
>> changes there when we make them.
>
> I'd rather see this in projects, not packages. So this would be in the
> root of an SVN project alongside of setup.py.
> Maybe this is what you meant.
>
>
>> The format I propose is in restructured text, like so:
>>
>> ==
>> zc.catalog changes
>> ==
>>
>> 0.2 (2006-11-22)
>>
>>
>> Features added
>> --
>>
>> * zc.catalog can now do even more wonderful things.
>>
>> Bugs fixed
>> --
>>
>> * fixed a bug where zc.catalog wasn't doing the right thing.
>>
>> What do you think?
>
> See what I've been doing for zc.buildout:
>
> http://svn.zope.org/zc.buildout/trunk/CHANGES.txt?view=auto
>
> Some things to note:
>
> I knit all of the .txt files, including documentation-oriented doctest
> files together in the distutils long description. This causes the pypi
> page to be pretty informative:
>
> http://www.python.org/pypi/zc.buildout
>
> The knitting happens in setup.py,
> http://svn.zope.org/zc.buildout/trunk/setup.py?rev=70198&view=auto
>
> While this is still pretty experimental, I'm pretty happy with it.
>
> To make this work requires coordinating headings across all of the text
> files. which lead to my use of *s in the root text files.
>
> Also, for individual packages, I think we can be a little more
> lightweight. For example, I think we can avoid separating features and
> bugs.
- -1. I *like* the split, as it forces the maintainer to think harder
about how to present the release to the world ("ultra-stable" vs.
"current" vs. "in development")
> I also think it's nice to provide some information about status and plans.
>
> I find putting dates on releases to be a bother. If it's a bother for
> me, it's probably a bother for others. Is it really worth it?
Absolutely. Correlating what release happended when by grubbing through
the logs is a chore, but better the releasing maintainer does it (once),
and then keeps it aligned, than have everybody who might need to use the
package have to do so.
> I've done a bad job of tagging releases, I need to get better about that.
>
> Finally, I'm experimenting with using launchpad for bugs:
>
> https://launchpad.net/products/zc.buildout/+bugs
>
> and feature requests:
>
> https://features.launchpad.net/products/zc.buildout/
>
> So far this is working OK. I haven't really stressed it. Launchpad makes
> this very easy to set up and I don't think they are allergic to having
> us create lots of projects.
If we're going to change horses, I'd rather go to something which can
correlate checkins with issues, via some kind of convention about
spelling the issue ID in the commit message (Trac, cvstrac, etc. do
this). I don't know whether launchpad can be persuaded to do this
(maybe via subscription to a checkins list?)
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFFZu2+gerLs4ltQ4RAkWYAKCLI/PHLTV5q2NshdXbRu+dxFnctQCffhmU
XS4CC2Uu6hvKajR1JVYDZHI=
=FzOf
-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: [Zope3-dev] Re: zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Sep 25, 2006, at 1:44 PM, Chris Withers wrote: > >> Jim Fulton wrote: >>>> It would *also* require that we >>>> implement the "no side-effects during parsing" policy (my other >>>> favorite >>>> "dead horse" in arguments about ZCML's implementation / usage). >>> Beat away. :) I've been in favor of this for some time. This is >>> definitely a goal. >> Can we have a papal edict that zcml that has side effects is a bug? >> (including the dotted name thing...) > > No, but I'm definitely in favor of refactoring existing handlers so > they do pretty much all of their work in the actions they generate. We'll need to remove the parse-time error checking of name resolution then, which means storing filename / line number information with each dotted name so that the failed resolution can be reported when actions are running. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGCT3+gerLs4ltQ4RAjubAKCAx3bjFDTQIJP2+NljAPNQJcwyYACglvno K4C1uDLz8e4M2MvIy1+w2TA= =srEr -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: emit ObjectModifiedEvent when object changed and zodb noticed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Hi All, > > Just been wondering about the need to retrofit: > > notify(ObjectModifiedEvent(self)) > > ...into lots of code. Can we do anything less intrusive? > > I mean, if a non-Zope object has changed, why should it have to think > about emitting events? I would say that, in general, "view code" should be emitting the events, rather than content objects. > In any case, could we do anything clever to do with event emitting when > objects are committed to the zodb? No. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGWWJ+gerLs4ltQ4RArOJAKCKyEgScvygoFXO1OSKp+8T4IsFZACglTnW OHC83OO1LK2vtvqDWwYiXG8= =ePmE -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: [Zope3-dev] Re: [z3-five] zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: > Chris Withers wrote at 2006-9-25 18:44 +0100: >> ... >> Can we have a papal edict that zcml that has side effects is a bug? >> (including the dotted name thing...) > > Hm: the purpose of "zcml" is to have side effects (register things, > patch classes with marker interfaces, add permissions, ...) But not during *parsing* of the ZCML: parsing is supposed to create a sequence of actions, which, when executed in sequence, make those changes. Because we check some kinds of errors too early (during parsing: in particular, we check the resolvability of "dotted names"), we force some directives to have "early" effects. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGWuy+gerLs4ltQ4RAjlIAJwK15uUCu6ZRTID+lYnQcsxekQCzQCfbkwI MukYTI07cG07nUAgdVudcTQ= =OU26 -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: Python version for Zope 3.4 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: > On 9/28/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: >> Jim Fulton wrote: >> > Baiju M wrote: >> >> Hi, >> >> What is the target Python version for Zope 3.4, is it Python 2.5? >> > >> > That's a good question. I fear it will take a fair bit of work to >> > get to it and, frankly for me there are higher priorities. >> >> I think we'd be okay in not supporting Python 2.5 yet for this release. >> Python 2.5 has just been released, and the 9 months or so will give it >> time to gell out, Python extensions a bit of time to catch up with the >> newer version, and for us to do some experimenting. Linux distributions >> will likely still be supporting Python 2.4 (along with 2.5) at that >> stage as well. > > Are you talking not-supporting Python 2.5 at all? Or just not wanting to > require it? The proposal is not to support it at all, unless somebody "takes one for the team" and works out all the nasty breakage which 2.5 induces on Zope. > If Zope 3 can't at least run on Python 2.5 within three months of > Python 2.5's release, I don't think that looks good for us. I would > hope that by being more "Pythonic" and free from the old > ExtensionClass magic - especially in Zope 3 - that Zope could keep > better pace with Python. But nine months? A year? Can I expect the > developers of toolkits we use, in some cases more heavily than Zope > itself, like SQLAlchemy to hold off on requiring Python 2.5 for that > long? The change from 2.4 to 2.5 is *massively* disruptive for a framework like Zope: much more so than any change since 2.2, I think (maybe even 2.0/2.1). The hardest bit is the change to the way the compiler works: RestrictedPython is completely incompatible with the new AST-based strategy. >> So unless a volunteer steps up to do lots of hard work between now and >> march next year, let's stick with Python 2.4. Otherwise let's plan it in >> for Zope 3.5 and Zope 2.12 > > I really really really hope it doesn't take that long to be able to > at least run on Python 2.5: even if it has to be with some caveats or > mild warnings. > > If security and restricted python / security proxies are the main > issue, what about if one is running Zope sites with absolutely ZERO > through the web code - no page templates, nothing - can't there be a > lighter weight security implementation that wouldn't take half a year > of "lots of hard work"? Even if you have no templates defined TTW, Zope3's security machiner still needs some support from RestrictedPython for handling filesystem-based templates. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFHJr3+gerLs4ltQ4RAnmFAKCuFkvWIAVn60mLP8AIik9LcttATgCcDrIL KQjhDIoPaj9N9pL1JHGIZU4= =D1Zt -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: __all__ for zope.schema
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fernando Correa wrote:
> Hi
>
> I was just wondering if it would be interesting to have a __all__ list
> just like zope.interface has.
> This would be cool for someone (like me :-) ) that is trying to get
> all the usable Fields that zope.schema provides.
>
> code:
>
>>>> import zope.interface
>>>> zope.interface.__all__
> ('Interface', 'Attribute', 'implements', 'directlyProvidedBy',
> 'classImplementsOnly', 'implementsOnly', 'moduleProvides',
> 'alsoProvides', 'directlyProvides', 'implementer', 'implementedBy',
> 'noLongerProvides', 'Declaration', 'providedBy', 'classProvides',
> 'classImplements')
>>>> import zope.schema
>>>> zope.schema.__all__
> Traceback (most recent call last):
> File "", line 1, in ?
> AttributeError: 'module' object has no attribute '__all__'
>>>>
>
> I just think that similar approach would give a better index for the
> package.
- -1, mostly becuase '__all__' is primarily intended to support the
'import *' misfeature in Python; any change which encourages 'from
zope.schema import *' cannot be the Right Thing (TM).
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFJQ+O+gerLs4ltQ4RAgFqAJ0bNiokCcoZcVtda0xo22m/4HmSNwCfZVUX
Teuq8bF0v0SmapXurtQV9iE=
=bSRF
-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: zope.testing.testrunner: issue with remove_stale_bytecode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > Wichert Akkerman wrote: >> Previously Andrew Bennetts wrote: >>> The real problem as you noted in your original message is that >>> there's no way to >>> distinguish between a pyc file that is only intended to be used as a >>> cache of >>> bytecode for a py file, and a pyc file that is intended to be used >>> standalone. >> >> Isn't the existing or non-existing of a corresponding .py file a good >> indication? > > No, because you may have intended to remove the module. Marking the directories containing the sourceless .pyc files as readonly would be a reasonable workaround: if your forgot the '-k', the testrunner would just whine and halt. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLWiZ+gerLs4ltQ4RAls5AJ4uWRuEx3mG4QUignNAk6GAOG9LnACgipti HwY/HqIds70ZCIecVeHpA/g= =WmcQ -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 distribute SSL server keys and certs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > > I'll probably reveal my ignorance of SSL here, but it is worrisome to me > that we distribute a PEM file that contains a default server key and > certificate. This seems like an exceedingly bad idea. It is. > We also distribute a private key to be used for sftp. (Shouldn't there > be a corresponding public key?) This seems like a very bad idea too. Keys should be generated inside 'mkzopeinstance.py', never shipped. We should probably add scripts for (re)doing the generation, as well. > The good news is that neither are these are enabled by default, however, > there are commented examples in the configuration file with comments > blithely telling people to uncomment them to get HTTPS or SFTP support, > using public "private" keys. > > Am I missing something? I don't think so. I didn't realize that we were shipping them at all. Are the shipped certs part of Twisted? In that case, we need to report this as an upstream bug. > BTW, are there tests of the HTTPS and SFTP support? No se. Remove the code and see what breaks ;). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFMbFo+gerLs4ltQ4RAhWDAJ9fEynyLnvY3OJjaWIyrzf9AVliBQCfatGh n802vxTRnPwfpG9W+2AHI48= =1OnO -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: testing and savepoints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Hi all, > > (sorry if some of this is Zope 2 - ish, the thread kinda started here > and the underlying bits of this are certainly relevant to Zope 3) > > As you may have guessed by the flurry of mails today, I've been > refactoring a 2000 test suite to use layers. > > I was hoping to use savepoints to speed things up... > > Each layer drops a savepoint in setUp and then rolls it back it in > tearDown. Likewise, the TestCase's setUp would drop a savepoint and the > tearDown would roll back to it. > > Sounds great, no? > > Well, no, actually: > > 1. Usual problems of some datamanagers not supporting savepoints. > MaildropHost and some of the project's own products datamanagers do. > mxODBC does not :-/ > > 2. dropping savepoints is slow. Figuring this might be due to saving > data from the layer each time transaction.savepoint() is called, I > thought of getting round this by dropping a savepoint at the end of the > layer's setUp method. This did make thing a litte better, but: > > 3. savepoints are really slow :-( > > What's the usecase for savepoints? I would have thought this kind of > thing would be ideal, but they seem really slow... > > For example, the above test suite takes about 300s to run prior to > introducing layers. > > Using savepoints in place of transaction.commit()'s meant it took over > 400s! :-( > > So I'm left what the actual use for savepoints is and if they could be > made any faster? Dunno, but this question belongs on zodb-dev. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNRbm+gerLs4ltQ4RArYgAJ9NYbG6fk3dL2D554JYkr1WxX17IgCg1UKU 2r+I33mqdDRHaUWTPKyvXfc= =h1Tg -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: zope.i18n dependency in zope.configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > On 10/22/06, Baiju M <[EMAIL PROTECTED]> wrote: >> So any module imported should be added as a dependency. >> Then, what about modules imported in test files (*.txt or test*.py >> files) ? > > Pretty much; there are cases where a package might import something > conditionally in order to improve integration, but if it isn't > available, the package as a whole can function just fine on its own. > In those cases, no dependency should be recorded. > > Ideally, dependencies of the implementation and the tests should be > separated, but we've been treating them as one so far. Moving to eggs > should allow improvements along these lines. Rkght: we should record that using the "extra" features of eggs[1] (so that the dependency is pulled in, but only if that feature is required). [1] http://peak.telecommunity.com/DevCenter/setuptools Tres - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFO6Kv+gerLs4ltQ4RApfWAJwPsipjprz88WkzOIRVcpuJFcWsogCgkzsA IVZ9I1duQIthrhTMLeR1lGM= =U686 -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: RFC: Zope Configuration Egg Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: > Jim Fulton wrote: >> Perhaps we should change the package option so that it uses the >> pkg_resources >> API to load ZCML files from packages. > > +1 I'd prefer not having to specify if the source was an egg or just a > "normal" package. +1 here as well, because it avoids breaking user-edited ZCML for the "simple" case (a package which used to be installed traditionally is now installed as an egg). The rarer cases (namespace packages, or those whose egg names don't match their package names) may still require the extra syntax. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFPLmP+gerLs4ltQ4RArVTAJ9HGvJsDi7yKFiDXolJMb7Sm2uBlACfXCsr GQsQZxSPbPLZd+wGBLFVRys= =m9EQ -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: [Checkins] SVN: zope.fssync/trunk/ Initial commit of zope.fssync for eggification.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: > Baiju M wrote: >> On 10/29/06, Benji York <[EMAIL PROTECTED]> wrote: >>> I'm really glad to see so much work being done on eggification, but am a >>> little concerned as to the mechanics. I'm worried that if dozens of >>> packages are separated out before they are actually knit into Zope >>> proper, we'll get drift between the two. >>> >>> It would seem to make more sense to eggify one or a few packages and get >>> them properly working in the core, and then go from there. >> >> zope.fssync and some other packages are not distributed with Zope 3. > > That doesn't answer my question, for two reasons. There are still > duplicate copies of the code. I suspect we should be removing the code > from the core tree as the packages are separated out (of course we have > to have a story for people who use those packages from the trunk first). Leave an 'svn:external' behind to the new location, perhaps with a 'DEPRECATED.txt' file stating when the external would go away? > Also, there are several packages that have been copied that /are/ > included in the core. Again, 'svn:external' is the way to avoid the duplication. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFRipk+gerLs4ltQ4RAig6AKCpsRi8ujRQIhV7cG7pzNncDDOSuACfe2D5 aoGikoyTk16vn846i2eDboE= =P0Nb -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: [OT] Python interpreter examples in Thunderbird
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: > Martin Aspeli wrote: >> OT: Thunderbird makes a real mess of interpreter examples, thinking the >> '>' is an indent and making it a coloured line. Anyone got an idea how I >> stop it from doing that? > > If you find out, PLEASE tell me too. :-) I use "View | Message Source" to deal with that. Tres. - -- ======= Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFU59Q+gerLs4ltQ4RAmEpAJ94TXnMSJaoy5w2Az/1aAJI4EVA0wCgo0ox Wg64/Ety5yhDZp7GFnGquqg= =IcLf -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: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Chris Withers wrote: >> Christian Theune wrote: >>> The problem you have is to provide a specification for the 'str' >>> interface. >> There are a couple of problems here... >> >> 1. str is both a "function" and a "class" > > Nope. It's a class since Python 2.2. > >> 2. I was to register the "function" str as an adapter for, say, the >> "class" int to the "class" str, so there's not factory for the adapter, >> since it's a function >> >>> Let's create a marker interface that promises everything that 'str' does: >>> >>> class IString(zope.interface.Interface): >>> """A marker for the 'str' interface.""" >> As discussed elsewhere, you shouldn't need the marker interface, as you >> can adapt classes. > > Right, as an *input* of the adaption it's ok just to specify a class. > But the output obviously always has to be specified by an interface. > Otherwise the whole point of using of adaption is perverted... Like adapting to None? Using adaptation to look up "value factories" is not any weirder than using it to look up event subscribers whose return values are always discarded. Thnk of cataloguing / indexing use cases: adapting the catalogued object to a string value (or tuple, or whatever) using named adapters is a very "natural" way to make indexing pluggable: what is *unnatural* (or at least a "dead chicken") is the requirement to adapt to an 'IString', when what I really want is a 'str'. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWK2o+gerLs4ltQ4RAsNxAJ4uXSOSup8PyQd2lQPm1Fqr/C3fGgCgwmiG PgKweYkpKMpulOK46qtJFx0= =twN/ -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: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Tres Seaver wrote: >> Thnk of cataloguing / indexing use cases: adapting the catalogued >> object to a string value (or tuple, or whatever) using named adapters is >> a very "natural" way to make indexing pluggable: what is *unnatural* >> (or at least a "dead chicken") is the requirement to adapt to an >> 'IString', when what I really want is a 'str'. > > Well, part of Python idea is duck typing and requiring that you get a > 'str' may be too much. Perhaps you would really only like to get > something that quacks like str. OTOH, perhaps you absolutely want a > 'str' and that use case should perhaps be allowed... Heh, in this case using 'IString' is really a "trussed duck" (duck typing with B&D) ;) Python's duck typing breaks down with strings, because they can by "quack tested" like sequences, but you almost *never* want to treat them the same way as other sequences, so you end up with 'isinstance(obj, basestr)' tests to prevent handling them that way. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWLUf+gerLs4ltQ4RAt/1AKCUvR230iCgNOq7kUpqAcFrSQVp5wCfedXY WI/ty3z7ektpMS/9Mh+l/PI= =IM7g -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: Can an adapter find out what name it was registered for?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Chris Withers wrote:
>> Can a named adapter find out the name it was registered with during the
>> adaptation process?
>
> Nope.
But you can create the adapter factories in such a way that they know
that name, via a little "curry powder":
>>> map = {}
>>> for name in 'foo', 'bar', 'baz':
... def whoami(name=name):
... return name
... map[name] = whoami
...
>>> map['foo']()
'foo'
>>> map['bar']()
'bar'
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFXRsj+gerLs4ltQ4RAtHSAKC85EasxcDQpCTDaY7AGT2lHpP7egCeJ12k
qaUxJBox8tQ1Pz5LWw99IHk=
=zgNn
-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: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Philipp von Weitershausen wrote: >> >>> IZopeDublinCore(obj) >> >> is a flexible version of >> >> >>> ZDCAnnotatableAdapter(obj) >> >> Flexible, because a different implementation that ZDCAnnotatableAdapter >> might be used. That's dispatched through the adapter registry. > > Right, exactly. > >>> IZopeDublinCore(myobj) does an adapter lookup based on the type of >>> 'myobj' >> That's the lookup in the registry (part 1 of the adapter call) >> >>> and returns an adapter instance with myobj as context, ready to be used. >> That's the instantiation a la str(123) (part 2 of the adapter call) > > Ah, I think this is becoming clearer... > > So, as another example, I could register the following as a factory for > turning instances of DateTime instances into datetime instances: > > def convert_dates(date): > return datetime(year=date.Year(),month=date.Month(),day=date.Month()) > > The important thing here, for me, is that the adapted value is not an > instance of the adapter factory. Factories return objects -- that's what they are for. If you register a class as an adapter factory (which the vast bulk of Zope3 applications do) then the adapter returned by the factory will be an instance of that class, because calling the class gives you an instance. Note that in the terms used in Zope3, the *returned object* is the adapter: the callable is the thing which *makes* adapters. Any callable which takes the appropriate number of arguments can be registered as a factory: the only contract is that the return value from the callable is supposed to implement the interface for which the factory was registered. The only (current) exception is "subscription adapters", which are registered for 'None' rather than an interface: their return value is *ignored*, because they do all their work when called. We were discussion a (notional) "value adapter", whose factory would have the contract of returning an object of a specific concrete type, rather than on implementing an interface. There are reasonable usecases for such adapters, but the CA machinery doesn't permit registering them: it requires that the 'provided' argument be either an interface or None (although the 'required' args can be concrete types). Hope that clarifies, rather than confuses, the discussion. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXR3u+gerLs4ltQ4RAqjQAJ9FcZvkmqC3/xNQ6KOWKHZhRPJD9QCeIR52 SDaTro7khfMJLSM5w2BtsG4= =iGfr -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: wading through zcml...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: > Philipp von Weitershausen wrote: >> Shane Hathaway wrote: >>> However, I'm wondering what browser:page does to make something >>> publishable, that browser:view doesn't do. >> It creates a new class with an extra mix-in class that has a >> browserDefault method which in turn points to the template, method or >> __call__ attribute. > > If you don't mind explaining, I'd like to understand why this design was > chosen. Why does it create a new class instead of creating an instance > of a class? It seems like it's using advanced Python (class generation) > where ordinary Python (a class instance) will do just as well. > > If I'm not missing something important, I may try to rewrite that code. I *think* that the design predated the ability of the security machinery to use an instance-specific attriubute for the checker, and so the only feasible way to get the configuration-specified security settings was to generate code. Either that, or the implementor didn't understand how the checker machinery worked, and just "made it work." 'pushpage' has a view directive which uses instances, rather than generated classes: http://agendaless.com/Members/tseaver/software/pushpage Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXU6y+gerLs4ltQ4RAmEzAKDDATRzC8AN94myLUBAghrYAUvuQACgoo/5 AF8Yf4uOzdLSv6aYtGzIwEQ= =2tLN -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: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Tres Seaver wrote: >> We were discussion a (notional) "value adapter", whose factory would >> have the contract of returning an object of a specific concrete type, >> rather than on implementing an interface. > > Right, but the CA supports the use of classes instead of interfaces and > that works just fine here... > >> There are reasonable usecases >> for such adapters, but the CA machinery doesn't permit registering them: >> it requires that the 'provided' argument be either an interface or None >> (although the 'required' args can be concrete types). > > Nah, for both "provides" and "adapts" classes can be used in place of > interfaces just fine, and I've got this working just how I want it now :-) This doctest blows up on my machine when run against the Zope3 trunk: >>> from zope.component import getAdapter >>> from zope.component import provideAdapter >>> from zope.interface import Interface >>> from zope.interface import implements >>> class IFoo(Interface): ... pass >>> class Foo(object): ... implements(IFoo) >>> foo = Foo() >>> def get_a(x): ... return 'a' >>> def get_b(x): ... return 'b' >>> provideAdapter(get_a, adapts=(IFoo,), provides=str, name='a') >>> provideAdapter(get_b, adapts=(IFoo,), provides=str, name='b') >>> getAdapter(object=foo, interface=str, name='a') 'a' >>> getAdapter(object=foo, interface=str, name='b') 'b' The first 'provideAdapter' call raises an exeption because 'str' doesn't have an '__iro__'. The second *doesn't* raise, because the code which raised the first exception leaves an artifact in a module global. Bot lookups fail with 'ComponentLookupError'. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXbz6+gerLs4ltQ4RAhbKAJ9nIr2GI3MPNygbmNuqiPmYLU5aLwCgxv5G pb6cW4/y9gjzQdN5nDuz6kQ= =Os0S -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: RFC: should z.a.c.attribute.AttributeIndex index None values?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: > On Nov 17, 2006, at 10:23 AM, Adam Groszer wrote: > >> Hello, >> >> Solutions: >> >> a: No, do not keep None values in the catalog >>the current implementation works like this >>you are unable to ask the catalog for objects having None >>properties >> b: Yes, keep None values in the catalog >>you can ask the catalog for objects having None properties >> c: Let's keep the existing one that does not index None and have an >>AttributeIndexAlsoNone class which will index None values > > Did you see my reply in the other thread? > > If you make indexes keep track of None, it will need to be done in a > separate data structure because of the key homogeneity issues. This > is a less efficient approach than the zc.catalog approach. It can be > done either way. > > I recommend that you use zc.catalog, rather than reinventing > something that solves your problem. > > I suppose I don't care much, since we don't use the standard zope > value and keyword indexes anyway; if you must add the None feature, > then I only care, from a "let's not screw up our community software" > perspective, that it be implemented in a safe way. Keep your BTree > keys homogenous. I don't get this -- an OOBTree promises to index *objects* as keys; None *does* behave properly as a key when mixed with strings. You can't count on it sorting in a particular way, but it *is* consistent. Worrying about consistency across, e.g., a major Python version upgrade (the only thing which I can envision changing the partial ordering) doesn't justify throwing out 'None' as a legitimate indexable value in all cases. In general, I don't think the storage mechanism should dictate the *policy* choice, which is whether 'None' is a "meaningful" value for the index. In many cases, having 'None' as the value for an attribute is *not* the same thing as not having the attribute at all -- I'll agree with you that objects who don't have the attribute should not Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXgOb+gerLs4ltQ4RAqnYAJ9r/o4E5ptIHeW29rlDcj97qeabUACfe8yr 8T2gWGEpmkXGEb07qEq/hFQ= =IHm7 -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: Can an adapter find out what name it was registered for?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
> Stephan Richter wrote:
>> On Friday 17 November 2006 03:43, Chris Withers wrote:
>>> What do you suggest I do when the adapter needs to know the name it was
>>> registered for?
>> You can make the name part of the adapter API.
>
> Not sure what you mean by this?
>
>> However, I would suggest revising the design; I have never come across a
>> scenario where I wanted the name of the adapter be known within the adapter.
>> This seems to be a recipe for trouble.
>
> I don't think it'll be a common pattern, but it doesn't feel right to me
> that a named adapter (ie: one registered with a specific name) has no
> way of finding out what name it has been registered with...
The classic pattern here would be to create the "guts" of your adapter
as a class, and then curry the "factory" part which governs
instantiation of the class. You could double-curry the factory, as
well, if you wanted to avoid the class. E.g.:
class MyNamedAdapter(object):
def __init__(self, context, name):
self.context = context
self.name = name
def causeBrowToSweat(self):
return 'Sweating: %s' % self.name
def MNA_factory_maker(name):
def _curried(context, name=name):
return MyNamedAdapter(context, name)
return _curried
for name in ('vindaloo', 'madras', 'tiki_masala'):
globals()[name] = MNA_factory_maker(name)
and then in ZCML:
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFa6jg+gerLs4ltQ4RAoSlAJwJvyp3gWfI72Pt+t2wiE5ozPFQxQCfWxwU
yVagPjfHMhjbK7wfeDghjI8=
=7BoL
-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: Can an adapter find out what name it was registered for?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: > Chris Withers wrote: >> Benji York wrote: >>> Chris Withers wrote: >>>> I don't think it'll be a common pattern, but it doesn't feel right to >>>> me that a named adapter (ie: one registered with a specific name) has >>>> no way of finding out what name it has been registered with... >>> Because the same adapter can be registered more than once, it would >>> actually need to find out all the names with which it was registered. >> Really? Now this is a use case I hadn't thought of.. can you give me >> some examples of where you've run into this? > > I don't know that I have, but the component system doesn't preclude it > so anything we come up with will have to take it into effect. I have already used the same adapters registered under different names (including the default "empty string" name). The CA is about allowing component configuration to express policy, which sometimes means that reusing an adapter makes sense (e.g., one might override the 'bar' named adapter for a particular object, while leaving the 'foo' adapter alone; the fact that the "default" registration uses the same factory for 'foo' and 'bar' Just Works now). I would argue that having adapters which need to know their name is *very* unusual, in fact. >>> This seems somewhat analogous to a Python object being given multiple >>> names. In that case too, there is no way for the object to know what >>> it's names are. >> Hmmm, okay, but I'd counter with both Zope 2 and Zope 3 having the >> notion of an object knowing its own name. Certainly in Zope 2, >> everything has an id or .getId(). That pattern evolved for a reason ;-) > > Sure, where "everything" is defined as content space objects, other > objects more rarely. That "pattern" has actually been the source of a lot of lost hair in the past -- content itmes know their IDs, which means that renaming them involves modifying *both* the container *and* the item. There was a fishbowl proposal for Zope2 to move the ID into the acquisition wrapper, which would have removed the need for content items to know them. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbNMH+gerLs4ltQ4RAheTAJ4rQee1njxmI0t4BrNkn8ikLzNThwCfWp/b EHnI2flrrxL0d33v9oLudcg= =hm22 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
