[Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On Jul 13, 2007, at 5:40 AM, Lennart Regebro wrote: Hi all! On 4/16/07, Gary Poster [EMAIL PROTECTED] wrote: The work that Jim Washington and David Pratt have started recently to make lxml an XHTML generator/ZPT replacement [#1]_ has really excited me. It would be *great* with in-Zope pipelines [#2]_. I'm here at the grok-sprint at EuroPython and we are looking into getting a pipeline hooked in to add theming to HTML output. [The idea of this is to add the theming, that is design, viewlets and so on, by imposing it on the HTML output, instead of including it from the template. This would open up for template independency, or even skipping templates completely for simple HTML and instead just outputting it.] We are looking for recommendations and visions on how to do this pipelining with IResults, because it's not entirely clear to us at the moment. Main worries are the questions of how to differ between results that need to be themed and those who don't, I thought you'd return different objects, and rely on adapters. I'm a bit surprised at the question, actually--what have I missed? and also IResult seems to have to handle the encoding itself, which means we need to duplicate the encoding that is already going on in setResults. I think the responsibility is appropriate: IResult should be responsible for encoding, because who knows what it wants to return. Perhaps the factoring could be improved in the future, so that the encoding code could be a function that setResults uses, and your custom IResult adapter can too. For now, it hardly seems like a show- stopper. I have earlier (before IResult being made public) made a quick hack that inserts theming earlier in the process by replacing the BrowserPublication, maybe that's a better way to put theming? Doesn't appeal to me--feels like the hack that we did for zc.resourcelibrary, in which the change to the system is much, much too heavyweight (someday we'll convert it to using IResult, I suspect)--but you're doing it. :-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote: * zope.interface * zope.security * zope.app.container * zope.hookable * zope.i18nmessageid Could you or someone else make final source releases of these first? I expect that some of these haven't changed since Zope 3.3. We should not make new releases of eggs if they haven't changed. One of the great things about eggs is that we can stop releasing non-changes. :) In the short term, I'll go ahead and make windows eggs for the packages that have latest source distros. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
Jim Fulton wrote: On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote: * zope.interface * zope.security * zope.app.container * zope.hookable * zope.i18nmessageid Could you or someone else make final source releases of these first? I expect that some of these haven't changed since Zope 3.3. We should not make new releases of eggs if they haven't changed. One of the great things about eggs is that we can stop releasing non-changes. :) In the short term, I'll go ahead and make windows eggs for the packages that have latest source distros. I take that back. It looks like it's going to take more time than I have to figure out what releases to make. There are various versions floating around. Yes, I noticed that too. I think the current situtation is way too confusing. We should decide which the authoritative source for the eggs is, the CheeseShop or http://download.zope.org/distribution. The advantage of the latter is that everybody with checkin rights can release a new egg, whereas on the CheeseShop it takes access rights. Please either: Point me at an existing source release, and I'll be happy to generate corresponding windows eggs. I made windows eggs for the latest version of zope.interface that's in pypi. Great. So we have zope.interface and zope.proxy and there'll be no need for zope.thread. Which leaves us with: http://download.zope.org/distribution/zope.security-3.4.0b2.tar.gz http://download.zope.org/distribution/zope.app.container-3.5.0a1.tar.gz http://download.zope.org/distribution/zope.hookable-3.4.0a1.tar.gz http://download.zope.org/distribution/zope.i18nmessageid-3.4.0a1.tar.gz I realize that those aren't final releases, but they (most probably) haven't changed significantly after these releases were made, which would make it a waste of time if I had to tag and tarball them just for the sake of a different version ID. Thanks again Philipp P.S.: While looking around, I found that an ancient version of zope.security actually exists as a Win32 egg on the CheeseShop: http://cheeseshop.python.org/pypi/zope.security/3.4dev-r73262. I wonder why my Windows buildout didn't find it. Perhaps the egg doesn't satisfy a version dependency? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[2]: [Zope3-dev] problem with zope.testbrowser
Hello Benji, Did something at /repos/Zope3/branches/adamg-mechanize-update/, the biggest problems seems to be now, that ClientForm won't work in a subfolder. Any objections against putting it back to /src? Wednesday, July 11, 2007, 7:32:06 PM, you wrote: Adam Groszer wrote: The problem is deep in mechanize. Updating mechanize+Clientform to the current versions (locally) helped. Some patching in testbrowser is necessary. Cool! Glad you're looking into this. Any advices for/against doing that on the trunk? I would prefer a branch, that way we can collaborate on it before merging it to the trunk. -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
Philipp von Weitershausen wrote: P.S.: While looking around, I found that an ancient version of zope.security actually exists as a Win32 egg on the CheeseShop: http://cheeseshop.python.org/pypi/zope.security/3.4dev-r73262. I wonder why my Windows buildout didn't find it. Perhaps the egg doesn't satisfy a version dependency? After some searching, I found that zope.i18n depends on zope.security=3.4.0b1. That explains it. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[2]: [Zope3-dev] Windows eggs
Hello Philipp, Friday, July 13, 2007, 12:18:27 PM, you wrote: Adam Groszer wrote: Tried it with zope.proxy. Updated to the latest distutils. I trust you're also using setuptools? Now yes, was a clean VM :-S distutils is 1.0.2 setuptools is 0.6c6 Anything else I need? What happens with other packages? What happens with packages that don't have C extensions? The exception changed a bit, but still all packages have the same regardless of C extensions: Traceback (most recent call last): File U:\1\zope.viewlet-3.4.0a1\setup.py, line 57, in ? zip_safe = False, File C:\Python24\distutils\core.py, line 101, in setup File C:\Python24\Lib\site-packages\setuptools\dist.py, line 223, in __init__ _Distribution.__init__(self,attrs) File C:\Python24\distutils\dist.py, line 130, in __init__ AttributeError: DistributionMetadata instance has no attribute 'get___doc__' ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Windows eggs
Adam Groszer wrote: Tried it with zope.proxy. Updated to the latest distutils. I trust you're also using setuptools? What happens with other packages? What happens with packages that don't have C extensions? Have the following exception: Traceback (most recent call last): File U:\1\zope.proxy-3.4.0a1\setup.py, line 54, in ? zip_safe = False, File C:\Python24\distutils\core.py, line 101, in setup File C:\Python24\distutils\dist.py, line 130, in __init__ AttributeError: DistributionMetadata instance has no attribute 'get___doc__' what am I missing? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Windows eggs
Hello Philipp, Tried it with zope.proxy. Updated to the latest distutils. Have the following exception: Traceback (most recent call last): File U:\1\zope.proxy-3.4.0a1\setup.py, line 54, in ? zip_safe = False, File C:\Python24\distutils\core.py, line 101, in setup File C:\Python24\distutils\dist.py, line 130, in __init__ AttributeError: DistributionMetadata instance has no attribute 'get___doc__' what am I missing? Friday, July 13, 2007, 11:08:36 AM, you wrote: PvW Hi Jim, Adam, PvW can we take you up your offers to build Windows stuff? It would be PvW *extremely* great to have Windows eggs of the latest PvW * zope.interface PvW * zope.security PvW * zope.app.container PvW * zope.hookable PvW * zope.i18nmessageid PvW * zope.proxy PvW * zope.thread PvW Adam: Simply getting the latest tarball from PvW http://download.zope.org/distribution/. Running PvWpython setup.py bdist_egg PvW should do it. You can then scp the resulting .egg file in the 'dist' PvW directory to [EMAIL PROTECTED]:/distribution (you'll have to do PvW it one by one). PvW Thanks! PvW Philipp PvW P.S.: I've tried doing it myself by following the instructions on PvW http://www.vrplumber.com/programming/mstoolkit/, but without success. PvW ___ PvW Zope3-dev mailing list PvW Zope3-dev@zope.org PvW Unsub: PvW http://mail.zope.org/mailman/options/zope3-dev/agroszer%40gmail.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Gary Poster [EMAIL PROTECTED] wrote: We are looking for recommendations and visions on how to do this pipelining with IResults, because it's not entirely clear to us at the moment. Main worries are the questions of how to differ between results that need to be themed and those who don't, I thought you'd return different objects, and rely on adapters. I'm a bit surprised at the question, actually--what have I missed? Well, most HTML output is done by templates, which typically return unicode. I guess we can let the BrowerPublication to wrap the unicode in an object... I have earlier (before IResult being made public) made a quick hack that inserts theming earlier in the process by replacing the BrowserPublication, maybe that's a better way to put theming? Doesn't appeal to me--feels like the hack that we did for zc.resourcelibrary, in which the change to the system is much, much too heavyweight (someday we'll convert it to using IResult, I suspect)--but you're doing it. :-) Maybe. :-) But just after I pressed send I actually realized that one part of the theming is getting in viewlets therem which is quite difficult if you don't have the context, which actually again points at the Publication being the right place to do this. Or am I missing something? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Windows eggs
Hi Jim, Adam, can we take you up your offers to build Windows stuff? It would be *extremely* great to have Windows eggs of the latest * zope.interface * zope.security * zope.app.container * zope.hookable * zope.i18nmessageid * zope.proxy * zope.thread Adam: Simply getting the latest tarball from http://download.zope.org/distribution/. Running python setup.py bdist_egg should do it. You can then scp the resulting .egg file in the 'dist' directory to [EMAIL PROTECTED]:/distribution (you'll have to do it one by one). Thanks! Philipp P.S.: I've tried doing it myself by following the instructions on http://www.vrplumber.com/programming/mstoolkit/, but without success. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re-revisiting IResult (for in-Zope pipelining)
Hi all! On 4/16/07, Gary Poster [EMAIL PROTECTED] wrote: The work that Jim Washington and David Pratt have started recently to make lxml an XHTML generator/ZPT replacement [#1]_ has really excited me. It would be *great* with in-Zope pipelines [#2]_. I'm here at the grok-sprint at EuroPython and we are looking into getting a pipeline hooked in to add theming to HTML output. [The idea of this is to add the theming, that is design, viewlets and so on, by imposing it on the HTML output, instead of including it from the template. This would open up for template independency, or even skipping templates completely for simple HTML and instead just outputting it.] We are looking for recommendations and visions on how to do this pipelining with IResults, because it's not entirely clear to us at the moment. Main worries are the questions of how to differ between results that need to be themed and those who don't, and also IResult seems to have to handle the encoding itself, which means we need to duplicate the encoding that is already going on in setResults. I have earlier (before IResult being made public) made a quick hack that inserts theming earlier in the process by replacing the BrowserPublication, maybe that's a better way to put theming? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Jim Fulton wrote: On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote: * zope.interface * zope.security * zope.app.container * zope.hookable * zope.i18nmessageid Could you or someone else make final source releases of these first? I expect that some of these haven't changed since Zope 3.3. We should not make new releases of eggs if they haven't changed. One of the great things about eggs is that we can stop releasing non-changes. :) In the short term, I'll go ahead and make windows eggs for the packages that have latest source distros. I take that back. It looks like it's going to take more time than I have to figure out what releases to make. There are various versions floating around. Yes, I noticed that too. I think the current situtation is way too confusing. We should decide which the authoritative source for the eggs is, the CheeseShop or http://download.zope.org/distribution. The advantage of the latter is that everybody with checkin rights can release a new egg, whereas on the CheeseShop it takes access rights. Please either: Point me at an existing source release, and I'll be happy to generate corresponding windows eggs. I made windows eggs for the latest version of zope.interface that's in pypi. Great. So we have zope.interface and zope.proxy and there'll be no need for zope.thread. Which leaves us with: http://download.zope.org/distribution/zope.security-3.4.0b2.tar.gz http://download.zope.org/distribution/zope.app.container-3.5.0a1.tar.gz http://download.zope.org/distribution/zope.hookable-3.4.0a1.tar.gz http://download.zope.org/distribution/zope.i18nmessageid-3.4.0a1.tar.gz Are you asking that Windows folks run using these alphas as binaries? I don't quite see the benefit. I realize that those aren't final releases, but they (most probably) haven't changed significantly after these releases were made, which would make it a waste of time if I had to tag and tarball them just for the sake of a different version ID. Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Again, what kind of Windows user are you expecteing (wanting) to test these eggs? Thanks again Philipp P.S.: While looking around, I found that an ancient version of zope.security actually exists as a Win32 egg on the CheeseShop: http://cheeseshop.python.org/pypi/zope.security/3.4dev-r73262. I wonder why my Windows buildout didn't find it. Perhaps the egg doesn't satisfy a version dependency? - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl5Js+gerLs4ltQ4RAjsAAJ4+NCg81tWVOpYjK7FMM5TG6GqpGACgw3FF p6mFmmhOH+2GC+U7Ic9U6mI= =hb+y -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: Re-revisiting IResult (for in-Zope pipelining)
On Jul 13, 2007, at 6:06 AM, Lennart Regebro wrote: On 7/13/07, Gary Poster [EMAIL PROTECTED] wrote: We are looking for recommendations and visions on how to do this pipelining with IResults, because it's not entirely clear to us at the moment. Main worries are the questions of how to differ between results that need to be themed and those who don't, I thought you'd return different objects, and rely on adapters. I'm a bit surprised at the question, actually--what have I missed? Well, most HTML output is done by templates, which typically return unicode. I guess we can let the BrowerPublication to wrap the unicode in an object... No, the intent is that this is explicit in the view. I have earlier (before IResult being made public) made a quick hack that inserts theming earlier in the process by replacing the BrowserPublication, maybe that's a better way to put theming? Doesn't appeal to me--feels like the hack that we did for zc.resourcelibrary, in which the change to the system is much, much too heavyweight (someday we'll convert it to using IResult, I suspect)--but you're doing it. :-) Maybe. :-) But just after I pressed send I actually realized that one part of the theming is getting in viewlets therem which is quite difficult if you don't have the context, which actually again points at the Publication being the right place to do this. Or am I missing something? Here's what I was thinking. If you want a view to return an unprocessed unicode value (or perhaps lightly processed) then have it return the value. The end. The pipeline will do little or nothing to it. (zc.resourcelibrary might look for HTML-ness in the string and try to insert, but that's it). If you want it to be processed as part of a pipeline, then return an object that has what you think the pipeline will need. For instance, here's a very off-the-cuff version. There's a *lot* of room for figuring out different ways for this to work, which is one of the interesting bits, and why we've said, at least internally, let a thousand pipelines bloom...and then presumably just a few of them will settle down and win. class MyPipelineInput(object): # you might have multiple ones of these, with different info. # this is one of the patterns you would be innovating on. # you might declare interfaces here, or even in the view...or even # in the pipeline. your pipeline might say I keep on adapting until # I get a string, or until I've done more than X adaptations, which I # will regard as an infinite loop and so raise an error. Or you # might aim for another interface, or...or...or... def __init__(self, output, context, request): self.output = output self.context = context self.request = request # maybe you'd want to add __unicode__ so it could render as-is if desired? maybe add helpers to encode? class MyPipelineAwareView(BrowserPage): template = ...my template... def update(self): do stuff... def render(self): output stuff... def __call__(self): self.update() return MyPipelineInput(self.render(), self.context, self.request) As another variation, and one that made me excited, the view would return an lxml object, and you would adapt on that...which might eventually turn into a different kind of object, like the `MyPipelineInput` above, for further, different adaptation. You could also send a wrapper of the lxml object--even using a generic one like MyPipelineInput that then had an adapter that did a second dispatch on both itself and the output (and the request? and the context?) There are a lot of interesting variations possible here. We'll need to experiment for awhile to see what works, what is simple, and so on. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
On Jul 13, 2007, at 7:04 AM, Jim Fulton wrote: On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote: * zope.interface * zope.security * zope.app.container * zope.hookable * zope.i18nmessageid Could you or someone else make final source releases of these first? I expect that some of these haven't changed since Zope 3.3. We should not make new releases of eggs if they haven't changed. One of the great things about eggs is that we can stop releasing non-changes. :) In the short term, I'll go ahead and make windows eggs for the packages that have latest source distros. I take that back. It looks like it's going to take more time than I have to figure out what releases to make. There are various versions floating around. Please either: Point me at an existing source release, and I'll be happy to generate corresponding windows eggs. I made windows eggs for the latest version of zope.interface that's in pypi. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
Tres Seaver wrote: Point me at an existing source release, and I'll be happy to generate corresponding windows eggs. I made windows eggs for the latest version of zope.interface that's in pypi. Great. So we have zope.interface and zope.proxy and there'll be no need for zope.thread. Which leaves us with: http://download.zope.org/distribution/zope.security-3.4.0b2.tar.gz http://download.zope.org/distribution/zope.app.container-3.5.0a1.tar.gz http://download.zope.org/distribution/zope.hookable-3.4.0a1.tar.gz http://download.zope.org/distribution/zope.i18nmessageid-3.4.0a1.tar.gz Are you asking that Windows folks run using these alphas as binaries? I don't quite see the benefit. So I guess you don't see the benefit of releasing Windows binaries for alpha and beta releases. I realize that those aren't final releases, but they (most probably) haven't changed significantly after these releases were made, which would make it a waste of time if I had to tag and tarball them just for the sake of a different version ID. Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Right. *Proper* release management. I believe we have a volunteer release manager for that and for Zope 3.4 it's not me. Again, what kind of Windows user are you expecteing (wanting) to test these eggs? People who want to try out Zope 3.4 on Windows, in particular those who want to try out Grok, the buildout instance recipes and Zope-on-Paste on Windows. We've done some Zope 3.4 alpha and beta released, why shouldn't we make Windows eggs for those so that people can actually *try* them before a final release? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] CHANGES.txt (was: Windows eggs)
Tres Seaver wrote: Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Tres raises a good point. We should continue to maintain a CHANGES.txt or a 'Changes' section in README.txt for all zope.* projects now. And I would recommend that others do the same with z3c.* etc. packages. Calling the checkin police... :) -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] CHANGES.txt (was: Windows eggs)
On Friday 13 July 2007 11:07, Philipp von Weitershausen wrote: Tres Seaver wrote: Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Tres raises a good point. We should continue to maintain a CHANGES.txt or a 'Changes' section in README.txt for all zope.* projects now. And I would recommend that others do the same with z3c.* etc. packages. All eggified pacakges that I am involved in have a CHANGES.txt file for each release. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Jul 13, 2007, at 9:25 AM, Philipp von Weitershausen wrote: Jim Fulton wrote: On Jul 13, 2007, at 6:57 AM, Jim Fulton wrote: * zope.interface * zope.security * zope.app.container * zope.hookable * zope.i18nmessageid Could you or someone else make final source releases of these first? I expect that some of these haven't changed since Zope 3.3. We should not make new releases of eggs if they haven't changed. One of the great things about eggs is that we can stop releasing non-changes. :) In the short term, I'll go ahead and make windows eggs for the packages that have latest source distros. I take that back. It looks like it's going to take more time than I have to figure out what releases to make. There are various versions floating around. Yes, I noticed that too. I think the current situtation is way too confusing. We should decide which the authoritative source for the eggs is, the CheeseShop or http://download.zope.org/distribution. The advantage of the latter is that everybody with checkin rights can release a new egg, whereas on the CheeseShop it takes access rights. Once we reach steady state, I'd like to see everything in the cheese shop. Unfortunately, I hate crapping poorly packaged eggs there. : ( I'm not sure what to do about that given the time availability of current volunteers. It would be great if people who had time and were looking for easy projects would adopt some packages and make sure they are packaged well, especially with good overview information and on-line documentation. I don't have much time for this in the short term, although I'll certainly chip away at it in the long term. Please either: Point me at an existing source release, and I'll be happy to generate corresponding windows eggs. I made windows eggs for the latest version of zope.interface that's in pypi. Great. So we have zope.interface and zope.proxy and there'll be no need for zope.thread. Which leaves us with: http://download.zope.org/distribution/zope.security-3.4.0b2.tar.gz http://download.zope.org/distribution/ zope.app.container-3.5.0a1.tar.gz http://download.zope.org/distribution/zope.hookable-3.4.0a1.tar.gz http://download.zope.org/distribution/ zope.i18nmessageid-3.4.0a1.tar.gz I'll make Python 2.4 windows eggs today and put them there. I realize that those aren't final releases, but they (most probably) haven't changed significantly after these releases were made, which would make it a waste of time if I had to tag and tarball them just for the sake of a different version ID. We really need to get these to final. Most of our packages are stable and unchanging. Once we get them to final, we'll be able to mostly forget about them. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: Point me at an existing source release, and I'll be happy to generate corresponding windows eggs. I made windows eggs for the latest version of zope.interface that's in pypi. Great. So we have zope.interface and zope.proxy and there'll be no need for zope.thread. Which leaves us with: http://download.zope.org/distribution/zope.security-3.4.0b2.tar.gz http://download.zope.org/distribution/zope.app.container-3.5.0a1.tar.gz http://download.zope.org/distribution/zope.hookable-3.4.0a1.tar.gz http://download.zope.org/distribution/zope.i18nmessageid-3.4.0a1.tar.gz Are you asking that Windows folks run using these alphas as binaries? I don't quite see the benefit. So I guess you don't see the benefit of releasing Windows binaries for alpha and beta releases. I realize that those aren't final releases, but they (most probably) haven't changed significantly after these releases were made, which would make it a waste of time if I had to tag and tarball them just for the sake of a different version ID. Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Right. *Proper* release management. I believe we have a volunteer release manager for that and for Zope 3.4 it's not me. Right: you are asking that somebody do the release manager's job, or at least part of it. I was trying to point out that doing only a partial job (making binary installers for alphas) is likely to be troublesome. Note that under our proposed release regime, depending on an alpha makes *you* and alpha, too; is that what you want? Again, what kind of Windows user are you expecteing (wanting) to test these eggs? People who want to try out Zope 3.4 on Windows, in particular those who want to try out Grok, the buildout instance recipes and Zope-on-Paste on Windows. We've done some Zope 3.4 alpha and beta released, why shouldn't we make Windows eggs for those so that people can actually *try* them before a final release? Until somebody makes a release manager call that a package is stable enough for beta, I'd be really reluctant to ask people to test using binaries: they won't be able to develop or apply patches to test fixes, for instance, to bugs in the C extensions. Making it easier (via documentatin, likely) for *anybody* with an appropriate toolchain to build Zope's eggs on Windows would help, both by removing the need to built them before a real release, and by getting better feedback on platform-specific problems earlier in the cycle. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl5bv+gerLs4ltQ4RAmC5AJ9zb1Z8AZhvkD1mmsQGA4dvo9mURgCglFZB P3N0nPECSp/QrrEQ0iCffBc= =0NZ/ -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] CHANGES.txt (was: Windows eggs)
On Jul 13, 2007, at 11:07 AM, Philipp von Weitershausen wrote: Tres Seaver wrote: Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Tres raises a good point. We should continue to maintain a CHANGES.txt or a 'Changes' section in README.txt for all zope.* projects now. And I would recommend that others do the same with z3c.* etc. packages. Agreed. I recommend using a changes section in README.txt because it's tricky getting distutils to include other root-level files and I want to keep our setup scripts as simple as we can. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
Tres Seaver wrote: I realize that those aren't final releases, but they (most probably) haven't changed significantly after these releases were made, which would make it a waste of time if I had to tag and tarball them just for the sake of a different version ID. Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Right. *Proper* release management. I believe we have a volunteer release manager for that and for Zope 3.4 it's not me. Right: you are asking that somebody do the release manager's job, or at least part of it. I was trying to point out that doing only a partial job (making binary installers for alphas) is likely to be troublesome. Well, it's what Jim and Adam said they would be willing to do. Since Christian (the release manager for Zope 3.4) didn't create the Win32 eggs for the alphas and betas, I think it's legitimate to take them up on their offer to create the builds. Note that under our proposed release regime, depending on an alpha makes *you* and alpha, too; is that what you want? YES. I and others want to *test* the egg story on Windows. Apparently nobody has done this before (otherwise it wouldn't be such a big hassle to get those binary eggs) and I'd like to actually tests this before we release stuff as final. Is that so wrong? Again, what kind of Windows user are you expecteing (wanting) to test these eggs? People who want to try out Zope 3.4 on Windows, in particular those who want to try out Grok, the buildout instance recipes and Zope-on-Paste on Windows. We've done some Zope 3.4 alpha and beta released, why shouldn't we make Windows eggs for those so that people can actually *try* them before a final release? Until somebody makes a release manager call that a package is stable enough for beta, I'd be really reluctant to ask people to test using binaries: they won't be able to develop or apply patches to test fixes, for instance, to bugs in the C extensions. Making it easier (via documentatin, likely) for *anybody* with an appropriate toolchain to build Zope's eggs on Windows would help, both by removing the need to built them before a real release, and by getting better feedback on platform-specific problems earlier in the cycle. I tried to follow instructions from the web on how to get such a toolchain running on my Windows machine (see post scriptum to my very first email). It failed with an obscure error when compiling the extension. So, it seems at the moment there's no easily deployable toolchain. Having Windows test alphas and betas that they compile themselves is all fine and dandy, but unless we have a way for them to do that, this remains all but a pious wish. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] CHANGES.txt (was: Windows eggs)
On Jul 13, 2007, at 11:30 AM, Jim Fulton wrote: On Jul 13, 2007, at 11:07 AM, Philipp von Weitershausen wrote: Tres Seaver wrote: Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Tres raises a good point. We should continue to maintain a CHANGES.txt or a 'Changes' section in README.txt for all zope.* projects now. And I would recommend that others do the same with z3c.* etc. packages. Agreed. I recommend using a changes section in README.txt because it's tricky getting distutils to include other root-level files and I want to keep our setup scripts as simple as we can. Hm (and sigh). I was following what I thought was another Tres suggestion: put CHANGES.txt in the package, and a pointer in the top level to the package's version. Gary ___ 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: Windows eggs
On Friday 13 July 2007 11:23, Jim Fulton wrote: Once we reach steady state, I'd like to see everything in the cheese shop. Unfortunately, I hate crapping poorly packaged eggs there. : ( I'm not sure what to do about that given the time availability of current volunteers. It would be great if people who had time and were looking for easy projects would adopt some packages and make sure they are packaged well, especially with good overview information and on-line documentation. I don't have much time for this in the short term, although I'll certainly chip away at it in the long term. What does a good package contain? I have tried hard to follow the example of the existing packages, but are they good? I think we need to develop some guidelines first, before we can ask people to do the work. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
On Jul 13, 2007, at 11:14 AM, Tres Seaver wrote: ... I was trying to point out that doing only a partial job (making binary installers for alphas) is likely to be troublesome. Minor note: For library-ish things, I've decided to *stop* making installers. I'm only going to release binary distributions as eggs. Otherwise, dependencies are too hard to deal with. For something like an application, I think an installer makes sense, but then it should be self contained. I think if people get an installer, I think they expect to install it and have it work as is. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ 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: Windows eggs
On Jul 13, 2007, at 11:31 AM, Stephan Richter wrote: On Friday 13 July 2007 11:23, Jim Fulton wrote: Once we reach steady state, I'd like to see everything in the cheese shop. Unfortunately, I hate crapping poorly packaged eggs there. : ( I'm not sure what to do about that given the time availability of current volunteers. It would be great if people who had time and were looking for easy projects would adopt some packages and make sure they are packaged well, especially with good overview information and on-line documentation. I don't have much time for this in the short term, although I'll certainly chip away at it in the long term. What does a good package contain? I have tried hard to follow the example of the existing packages, but are they good? I think we need to develop some guidelines first, before we can ask people to do the work. Fair enough. We're still learning, but IMO, a could release should have: - a good overview, and preferably - on-line documentation Of course, the standard meta data should be filed in to a reasonable degree. Mainly what I'm looking for is a good faith effort. For example, IMO, zope.proxy is inadequate: http://www.python.org/pypi/zope.proxy/3.4.0 I released it anyway because it is a dependency of ZODB, but I wasn't happy. I really want to go bask and provide some basic documentation. We have soo much work to do on packaging. Oh well, we'll get their eventually. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On 7/13/07, Tres Seaver [EMAIL PROTECTED] wrote: You can't ask upstream to produce a thousand different pipelineables; the interface there needs to be dirt simple, and *always the same.*. In particular, you can't return unicode *or* a pipelineable: that puts the policy choice in the wrong place. Right. Also, after further discussion of the issues, which I'll try to put down in a sprint-report, we have concluded that the correct place to do the theming-pipeline is most likely in the BrowserPublication, because there you have access to the context as well as the published object typically (being a view class). -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
Lennart Regebro wrote: On 7/13/07, Tres Seaver [EMAIL PROTECTED] wrote: You can't ask upstream to produce a thousand different pipelineables; the interface there needs to be dirt simple, and *always the same.*. In particular, you can't return unicode *or* a pipelineable: that puts the policy choice in the wrong place. Right. Also, after further discussion of the issues, which I'll try to put down in a sprint-report, we have concluded that the correct place to do the theming-pipeline is most likely in the BrowserPublication, because there you have access to the context as well as the published object typically (being a view class). Doesn't the published object, being a view class, have context and request as instance variables? object.context and object.request should work to access these things. Or am I missing something? -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: CHANGES.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Jul 13, 2007, at 11:30 AM, Jim Fulton wrote: On Jul 13, 2007, at 11:07 AM, Philipp von Weitershausen wrote: Tres Seaver wrote: Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Tres raises a good point. We should continue to maintain a CHANGES.txt or a 'Changes' section in README.txt for all zope.* projects now. And I would recommend that others do the same with z3c.* etc. packages. Agreed. I recommend using a changes section in README.txt because it's tricky getting distutils to include other root-level files and I want to keep our setup scripts as simple as we can. Distutils sucks in this regard. Hm (and sigh). I was following what I thought was another Tres suggestion: put CHANGES.txt in the package, and a pointer in the top level to the package's version. That is still my preference: I think a people are more likely to find a changelog that way. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl60o+gerLs4ltQ4RAmNmAKCKQPQME/pdBN087ADCZ4suwHAHFwCgz5fi R+elhyT0jmgcJ7ZJoD00lMU= =x0f/ -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: Windows eggs
On Friday 13 July 2007 12:14, Jim Fulton wrote: IMO, a could release should have: - a good overview, and preferably - on-line documentation Right, I think this is well-served for packages that have doctests. I think that your example of including the dotest files into the long description is a good thing. However, I have noticed some problems with regard to PyPI: 1. It does not support unicode. I had some problems with characters before, but I cannot remember the details. 2. The PyPI website does not encode the long description, causing text with HTML to not display correctly. I have avoided this problem by escaping the long description myself, but then you loose the REST conversion. (See z3c.form.) Of course, the standard meta data should be filed in to a reasonable degree. Okay, I think most of the packages provide a lot of the info with exception of the Trove classifiers. They are very important for marketing reasons, because the PyPI Package browser (http://cheeseshop.python.org/pypi?%3Aaction=browse) recognizes them and uses them to organize the packages. I think it would be awesome, if it would say: Zope 3 (300 [packages]). OT: Did you notice that 17 out of 20 package updates today where Zope-related? :-) Mainly what I'm looking for is a good faith effort. I think in the long term it will be most beneficial, if we convert all tests to doctests; then a reasonable on-line documentation is not that hard to provide. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] CHANGES.txt (was: Windows eggs)
On Jul 13, 2007, at 11:34 AM, Gary Poster wrote: On Jul 13, 2007, at 11:30 AM, Jim Fulton wrote: On Jul 13, 2007, at 11:07 AM, Philipp von Weitershausen wrote: Tres Seaver wrote: Doing proper release management can't reeally be called a waste of time (that would include documenting exactly what *has* changed). Tres raises a good point. We should continue to maintain a CHANGES.txt or a 'Changes' section in README.txt for all zope.* projects now. And I would recommend that others do the same with z3c.* etc. packages. Agreed. I recommend using a changes section in README.txt because it's tricky getting distutils to include other root-level files and I want to keep our setup scripts as simple as we can. Hm (and sigh). I was following what I thought was another Tres suggestion: put CHANGES.txt in the package, and a pointer in the top level to the package's version. That is reasonable too, although it's more work than what I'm suggesting. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ 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: Windows eggs
On Jul 13, 2007, at 11:38 AM, Philipp von Weitershausen wrote: I'm not sure what to do about that given the time availability of current volunteers. I would happily upload properly released stuff to the CheeseShop if I had access. Somebody thought I wanted to own pretty much everything -- so I do. If you want access to something, just ask. Seriously, I was hoping someone else would step forward. This is a task that is good for someone without deep knowledge and who wants to contribute. Please either: Point me at an existing source release, and I'll be happy to generate corresponding windows eggs. I made windows eggs for the latest version of zope.interface that's in pypi. Great. So we have zope.interface and zope.proxy and there'll be no need for zope.thread. Which leaves us with: http://download.zope.org/distribution/zope.security-3.4.0b2.tar.gz http://download.zope.org/distribution/ zope.app.container-3.5.0a1.tar.gz http://download.zope.org/distribution/zope.hookable-3.4.0a1.tar.gz http://download.zope.org/distribution/ zope.i18nmessageid-3.4.0a1.tar.gz I'll make Python 2.4 windows eggs today and put them there. Awesome. Thanks! If all I have to d is drive windows, this is very easy for me. I just have to download, untar, and execute a single command per python versions that creates the egg and uploads to PyPI. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re-revisiting IResult (for in-Zope pipelining)
On Jul 13, 2007, at 12:30 PM, Lennart Regebro wrote: On 7/13/07, Tres Seaver [EMAIL PROTECTED] wrote: You can't ask upstream to produce a thousand different pipelineables; the interface there needs to be dirt simple, and *always the same.*. In particular, you can't return unicode *or* a pipelineable: that puts the policy choice in the wrong place. Right. Also, after further discussion of the issues, which I'll try to put down in a sprint-report, we have concluded that the correct place to do the theming-pipeline is most likely in the BrowserPublication, because there you have access to the context as well as the published object typically (being a view class). Hm, too bad. Gary ___ 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: Windows eggs
On Jul 13, 2007, at 1:14 PM, Stephan Richter wrote: On Friday 13 July 2007 12:14, Jim Fulton wrote: IMO, a could release should have: - a good overview, and preferably - on-line documentation Right, I think this is well-served for packages that have doctests. I think that your example of including the dotest files into the long description is a good thing. I need to get better though on making sure it is truly documentation and not just test. For example, I think it would be better if the online buildout documentation was easier to use. However, I have noticed some problems with regard to PyPI: 1. It does not support unicode. I had some problems with characters before, but I cannot remember the details. 2. The PyPI website does not encode the long description, causing text with HTML to not display correctly. I have avoided this problem by escaping the long description myself, but then you loose the REST conversion. (See z3c.form.) What I've doe with PyPI is a nice hack -- no more. It would be nice if some tool made it easy to maintain project home pages. I might like something better, but I can live with the hack for now. :) Of course, the standard meta data should be filed in to a reasonable degree. Okay, I think most of the packages provide a lot of the info with exception of the Trove classifiers. They are very important for marketing reasons, because the PyPI Package browser (http://cheeseshop.python.org/pypi?% 3Aaction=browse) recognizes them and uses them to organize the packages. I think it would be awesome, if it would say: Zope 3 (300 [packages]). Yup OT: Did you notice that 17 out of 20 package updates today where Zope-related? :-) :) And Zope dependent. :/ Mainly what I'm looking for is a good faith effort. I think in the long term it will be most beneficial, if we convert all tests to doctests; then a reasonable on-line documentation is not that hard to provide. Of course, I'm a big fan of doctest. Not all tests are documentation though, even if they are written as doctest. I'm happy with what we've done. We're making good incremental progress. I think though that many of our doctests that aspire to be documentation are actually not good documentation. IMO, we need to separate tests into 2 classes: executable documentation and tests. The executable documentation needs to be **much more readable than it is now**. I need to start using the footnote feature that Benji and Gary added. I suspect that that would help. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to debug zope3 if it completely hangs?
Fabio Tranchitella wrote at 2007-7-12 15:46 +0200:
...
I tried the suggestions from Benji, but using gdb and the commands from
debug-spining-zope results in a segfault of the zope3 instance I'm
debugging.
You could try the following gdb commands:
def ps
x/s ({PyStringObject}$arg0)-ob_sval
end
def pfr
ps f-f_code-co_filename
ps f-f_code-co_name
#p f-f_lineno
lineno
end
define lineno
set $__co = f-f_code
set $__lasti = f-f_lasti
set $__sz = ((PyStringObject *)$__co-co_lnotab)-ob_size/2
set $__p = (unsigned char *)((PyStringObject *)$__co-co_lnotab)-ob_sval
set $__li = $__co-co_firstlineno
set $__ad = 0
while ($__sz-1 = 0)
set $__sz = $__sz - 1
set $__ad = $__ad + *$__p
set $__p = $__p + 1
if ($__ad $__lasti)
# break -- interpreted as breakpoint
set $__sz = -1
end
if ($__sz = 0)
set $__li = $__li + *$__p
set $__p = $__p + 1
end
end
printf %d\n, $__li
end
pfr (Print FRame) can be used in PyEvalFrame (C level) call frames
to determine which Python code belongs to the respective call frame.
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
Hi, Philipp von Weitershausen wrote: I tried to follow instructions from the web on how to get such a toolchain running on my Windows machine (see post scriptum to my very first email). It failed with an obscure error when compiling the extension. So, it seems at the moment there's no easily deployable toolchain. Having Windows test alphas and betas that they compile themselves is all fine and dandy, but unless we have a way for them to do that, this remains all but a pious wish. Have you seen my instructions for a Plone 3.0 buildout at http://svn.plone.org/svn/plone/ploneout/trunk/WINDOWS.txt ? They are based on the MinGW C compiler and I and quite a lot other people have successfully built all of Zope's C extensions this way. The important parts are the 'MinGW' and 'Configure Distutils to use MinGW' sections. Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Windows eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Friday 13 July 2007 12:14, Jim Fulton wrote: IMO, a could release should have: - a good overview, and preferably - on-line documentation Right, I think this is well-served for packages that have doctests. I think that your example of including the dotest files into the long description is a good thing. However, I have noticed some problems with regard to PyPI: 1. It does not support unicode. I had some problems with characters before, but I cannot remember the details. 2. The PyPI website does not encode the long description, causing text with HTML to not display correctly. I have avoided this problem by escaping the long description myself, but then you loose the REST conversion. (See z3c.form.) Of course, the standard meta data should be filed in to a reasonable degree. Okay, I think most of the packages provide a lot of the info with exception of the Trove classifiers. They are very important for marketing reasons, because the PyPI Package browser (http://cheeseshop.python.org/pypi?%3Aaction=browse) recognizes them and uses them to organize the packages. I think it would be awesome, if it would say: Zope 3 (300 [packages]). OT: Did you notice that 17 out of 20 package updates today where Zope-related? :-) Mainly what I'm looking for is a good faith effort. I think in the long term it will be most beneficial, if we convert all tests to doctests; then a reasonable on-line documentation is not that hard to provide. - -1. Good tests don't always make good documentation; I prefer the isolation of traditional unittests for anything other than main line use cases, for which doctests are best suited. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl9UG+gerLs4ltQ4RAieBAJ9YFESD+JSi4d8NX+NpOEzBaOQQ8gCgy9tz fPqgeZ/Rc3V/1HFnvYFKNYk= =gi4m -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: Windows eggs
Previously Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Friday 13 July 2007 12:14, Jim Fulton wrote: IMO, a could release should have: - a good overview, and preferably - on-line documentation Right, I think this is well-served for packages that have doctests. I think that your example of including the dotest files into the long description is a good thing. However, I have noticed some problems with regard to PyPI: 1. It does not support unicode. I had some problems with characters before, but I cannot remember the details. 2. The PyPI website does not encode the long description, causing text with HTML to not display correctly. I have avoided this problem by escaping the long description myself, but then you loose the REST conversion. (See z3c.form.) Of course, the standard meta data should be filed in to a reasonable degree. Okay, I think most of the packages provide a lot of the info with exception of the Trove classifiers. They are very important for marketing reasons, because the PyPI Package browser (http://cheeseshop.python.org/pypi?%3Aaction=browse) recognizes them and uses them to organize the packages. I think it would be awesome, if it would say: Zope 3 (300 [packages]). OT: Did you notice that 17 out of 20 package updates today where Zope-related? :-) Mainly what I'm looking for is a good faith effort. I think in the long term it will be most beneficial, if we convert all tests to doctests; then a reasonable on-line documentation is not that hard to provide. - -1. Good tests don't always make good documentation; I prefer the isolation of traditional unittests for anything other than main line use cases, for which doctests are best suited. Amen. I find failing doctests to be much harder to debug as well. I use doctests as a method to make sure examples in my documentation are correct, which is very useful. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
