Re: [Zope3-dev] Re: The elevator speech for Zope 3
Hi Uwe. I have been thinking of something similar and posted on the list a couple of weeks back: http://mail.zope.org/pipermail/zope3-dev/2007-September/023653.html I want the zcml to be generated with a switch on zc.buildout so all configuration is auto generated. Currently site.zcml is done this way and I want to extend this to the class level. Recipe's would be produced to handle different types of configuration by providing the decorator methods. I'm hoping to use decorators exclusively on the classes to do this so there would be no need to modify the code in the classes themselves to accomplish the configuration. Further, classes without this decoration would be skipped by the process allowing this approach to be incorporated into your code gradually. I want to be able to see and verify the zcml produced and have the same control over it that I have now. The advantage of having it in buildout is that it becomes integrated into the development of the application, which is by nature just the configuration glue for your packages. Uwe, is there a chance your package can be zpl'd since I believe bebop is gpl and this is fairly low level code that could be a great plus for general z3 development. At the very least I'd like a zpl'd package to handle configuration this way or to borrow from your efforts to move forward with this idea. Regards, David Uwe Oestermeier wrote: Oliver Marx [EMAIL PROTECTED] writes: I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. Have a look at bebop.protocol in PyPI. It's still a preminary version but it does exactly what you want. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Hi Dieter. Zope 2 is one application among many dependent upon zope 3. Zope 3 is different software than zope 2. It has a community of pure zope 3 developers (that I don't believe the suggestion of folding the lists together adequately considers). Folks have been developing and collaborating on zope2 five and zope 3 all along with success. More so, I get the impression that the unstated goal here is to assimilate zope 3 into a different notion of 'zope' that would further obfuscate it as a framework (under the influence of zope2). Zope 3 stands on its own as a framework and I sure hope I am wrong about how I have been interpreting the dialog. If the objective is simply working together and staying better informed, it does not require a merged list to accomplish this. The objective of the zope3-dev list is to serve the development interests of zope3. Folks with input or who wish to monitor this should subscribe to the list. Regards, David Dieter Maurer wrote: David Pratt wrote at 2007-10-7 12:17 -0300: ... Zope 2 is a single application Are you sure you know Zope2 ? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
I agree with you Roger. I want things to stay as they are for the same reasons. I have great respect for Zope 2 developers however there there are two development paradigms at play that are fundamentally incompatible despite the inclusion of component architecture in Zope 2. Regards, David Roger Ineichen wrote: Betreff: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. -1 Not that I'm not interested in what's going on in Zope 2, but the two list let me easy separate this two different topics. And it will allow me to read the Zope2 mails in digest mode if I don't have time to read all. Another reason for not to switch is the mailinglist observation in the different web apps out there. They are very usefull. btw, a cool app, this is another reason to keep the trunk up and running. I guess they checkout our code and count the lines ;-). See: http://www.ohloh.net/projects/4495?p=Zope+3 e.g. Codebase 97,598 LOC Effort (est.) 25 Person Years Project Cost $1,348,258 Regards Roger Ineichen Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Hi Andreas. Let me say I see the development paradigms as being the following without prejudice to any application that depends upon zope 3. Respectfully, no one is building walls. my contribution to the discussion is not about isolating folks but of the reality of the software differences. zope 3 - an open framework - no borders, no boundaries - write and think as a python programmer. In essence zope 3 is is a framework without a frame. This fact that exists in this form gives it its elegance and power. It does not need to be an application and is more interesting when it is not. zope 2 - an application tied strongly the cmf with the notion of a cms as the app. It is self contained and it is able to absorb zope 3 packages and technologies. I see plone as an application layer build on top of the zope 2 application. The fact that zope 3 is not specifically an application, nor a traditional framework is also what can make it difficult for folks to distinguish zope 3 as something special. You only understand this once you are able to see it for what it is. To the uninitiated it may just seem a library of packages (and well, that's missing the point :-)) When one looks at the collection of software that makes up the python language, they see an elegant way to create. Zope 3 is like this and you are free to create anything you wish. Folks looking for containment within a framework will look for traditional solutions that confine their development within a container with strict rules and one way to do it all. This has strong points but the least of those is flexibility and diversity. Think if our creator had thought of only one way to create an animal and the possibilities and opportunities lost to create all the diversity we see on our planet. I've developed in zope2 and recognize and respect it as a powerful web platform that answers specific solutions. For me, considerable flexibility was lost when you are not programming as a python programmer and programming for the api of the application. I have always wanted what zope 3 provides. I do not want to see it given any other ground or see the development of zope 3 pushed or pulled by interests that best serve one application or another. Zope 2, Plone 3, SchoolTool, Grok, Bebop, and many commercial interests and projects including those by Lovely and others are beginning to show how diverse Zope 3 can be (and all have an interest in the development of zope 3). I should say this diversity extends to desktop applications as well as the web. Personally, I see zope 2 and 3 as distinctly different. The development is different and the goals are different. Collaboration is always a good idea but in the same way that any programmer depending upon zope 3 packages will want to maintain an interest in zope 3 development. I also see zope 2 developers in the same context as other application developers that utilize zope3 in their efforts. Collaboration can occur freely without merging the specific development lists or interests of grok-dev, zope-dev, plone and other application development (that would have simililar interests) in the development list of zope 3. I don't see zope as a synonym for zope 2 and zope 3 either, any more that I could see it as a synonym for SchoolTool and zope3 or Grok and zope 3 (though obviously all a part of the zope community with a special interest in zope 3). Common ground and unified forums for the community is a different interest than merging development lists for the software. zope 2 and zope 3 share the same name but it my opinion calling it all zope is really a bad idea and perpetuates a problem. Given the way history has unfolded, i'd have rather seen zope 3 given a new name, and have had an opportunity to have dissociated itself from zope 2 in a clear way without the premise or goal of trying to fold zope 2 'the application and zope 3 the framework without a frame together. It is alright (and frankly realistic) to suggest we have two software lines here that are very different. Personally, I don't see these ever being the same and future 'marketing' efforts should respect this if marketing is a concern. The notion of the zope 3 application is fading as it should with the developments of the last year. I wouldn't want to see zope 3 revert to something or extend parts that have it looking like the zope 2 of four years ago for the sake of unifying the developer community under a generic zope flag. In any case, long message, but I hope this clarifies my view on this. Regards, David Andreas Jung wrote: --On 6. Oktober 2007 12:03:06 -0300 David Pratt [EMAIL PROTECTED] wrote: I agree with you Roger. I want things to stay as they are for the same reasons. I have great respect for Zope 2 developers however there there are two development paradigms at play that are fundamentally incompatible despite the inclusion of component architecture in Zope 2
Re: [Zope3-dev] Re: [Zope] Static Zope 3 APIDOC available!
Very nice. Many thanks for this. Regards, David Baiju M wrote: Stephan Richter wrote: Hi everyone, I am happy to announce that the second Foliage sprint task is completed. Julian Bonilla, Graham Stratton and I worked on the outstanding issues on creating a functional version of the APIDOC, which comes with Zope. Thanks to Jens Vagelpohl, the static APIDOC is now available at: http://apidoc.zope.org I have also uploaded a TGZ archive to: http://download.zope.org/distribution/static-apidoc.tgz I hope that this development will spark renewed interest in the tool. In the future I plan to make more packages available in APIDOC and make it work with eggs. If you are interested, please let me know! Great news ! Congratulations to you all !! Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Grok or raw Zope?
Hi there. Best to post this on Zope3-users list for a response. Regards, David Matias Surdi wrote: I've posted this same message on grok-devel mailing list. I'm just looking for comments from the other side :-) Thanks a lot in advance. Hi, I'm going to start a new project in a few weeks and I'm evaluating possible frameworks to use. My best candidate at the momment is Zope 3, since I have a couple of years of experience with Python and Zope 3 provides most things I will need (such as authentication, templates, database access, workflows, etc..). We are going to build an intranet portal, where each department of the company (a software development one) has it's own area, and the application should provide applications for the needs of everyone, we need a bug tracking system, a support platform for our customers, a knowledge base for our employees and customers, an many other applications... So, I've no experience with Zope nor Grok. I would like to receive some advice about choosing Grok or Zope. I think Grok is more easy to start with, but... ¿will it in the future put any limit on a very big intranet application for an entire company? Thanks for your comments. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testbrowser packaging
Hi Benji. I don't like the first option. I am already using a zope extras to group packages for other reasons and don't really want to mix this with the test extra. I am trying to use extras as much as possible opposed to listing reams of packages in buildout.cfg to keep it cleaner and simpler. I don't mind the strange name to be honest, the namespaces are informative. Many thanks. Regards, David Benji York wrote: I have a small issue with zope.testbrowser packaging I'd like to get some input on. If I were to have started the project today, it would likely have been zc.testbrowser, which would have no Zope 3 dependencies (or functionality) and zc.testbrowser.zope, which would have, and depended on zc.testbrowser. Well, that didn't happen, but there are parallels to the current situation that might be informative. There is a configuration bug in testbrowser that means that unless you include the test extra, you won't get the Zope 3 dependencies. I suspect most people either include that extra, or accidentally include the dependencies through other packages. I have two ideas for fixing this: 1) introduce a zope extra that everyone will have to use (basically just rename test to zope; 2) take a lesson from the fictional zc.testbrowser and introduce another package (zope.testbrowser.zope) that contains the Zope 3 bits and depends on zope.testbrowser. I think I prefer the second, despite it's strange appearance. Thoughts? ___ 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: What does python 3000 mean for zope?
Hi Jim. Fair enough. This gives me better sense of the picture. In a year or two from now I would not be surprised to see jython at 2.5 which could be interesting for the python frameworks. It also has a plan to evolve to P3K as well. All python projects will get there regardless. I am certain there will be some anticipation to port packages when P3K is out the door or as it evolves. Personally, I want to stay on the front end of the language. A good part of my enjoyment in development is wrapped in working and moving with the state of the art. Regards, David Jim Fulton wrote: On Sep 11, 2007, at 10:28 AM, David Pratt wrote: I was hoping Jim might respond to this thread since I am certain there is concern about what this means for the future of Zope. I am hoping that core communities of python framework developers may come together on what is in their best interests. OK, here's my opinion. I am not speaking for ZC. I don't think we should worry until Python 3 is much farther along. I agree with those who think that it will be hard to move to Python 3. Put another way, I think the benefit won't be worth the effort. My suspicion is that this will be true for *lots* of projects. I expect Python 2 to be with us for a long time. This is just a wild guess. A lot can change in a year or 2. I think our official position should be that Zope is a Python 2 application and we'll evaluate opportunities to leverage Python 3 over time as they present themselves. I'm not going to reply to any replies to this post as I don't intend to spend any more time on this issue myself. Jim -- Jim Fultonmailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporationhttp://www.zope.comhttp://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: What does python 3000 mean for zope?
Hi Martijn. I think a tool to assess the impact on each project is necessary. A risk assessment of some type could realistically quantify, identify imported code, estimate of the size of the community depending upon the sources, provide rough conversion estimates, and also identify alternatives to P3K. Risk assessments for the frameworks teams (willing to conduct an assessment) can be put together with a general impact statement from the framework and library project leaders and presented to the python team. Efforts should be coordinated with deadlines. A statement of general impacts could include those anticipated by the communities being served by sources, and include general impacts assessed on future marketing and consumption of what will soon become legacy code. It should also include an answer to why porting to P3K will be different that previous porting scenarios. The effort should include the formulation of recommendations to the python team. The objective is not to restrict the effort of the python team, but to assist the team in guiding their decisions. It is more difficult to dismiss facts and figures. Before proceeding with anything, the perspective from our own project leadership needs to be communicated and clarified. I have not yet heard anything from Jim or Zope Corporation on whether there may already be a plan of sorts to address P3K. I'm only willing to become involved on the basis there is consensus from our own project and that the effort is supported. I would recommend the Zope Foundation meet on this soon to at least build consensus and agreement on how this effort should be handled. Consultation with the Plone Foundation would go a long way in establishing their buy-in to this process. I believe a general statement should be communicated back to the zope lists in the form of an announcement when an assessment/coordination strategy has been determined. It ought to convey the action that will be taken to assess the impact and the efforts that will be made to coordinate with other projects to meet the future python release. This should give folks a sense that something is being done to work together cooperatively with our communities and the python team to address change. If there is consensus, I'd recommend the ZF appoint at least one key Board member to direct and to be accountable for these efforts. This will be a critical junction in zope's history. I am not a ZF member but am prepared to assist with this effort together with other interested folks. Regards, David Martijn Faassen wrote: Hey, David Pratt wrote: [snip] Communication with the core python team on impacts could create a cohesive strategy for the future and improve buy-in if there can be agreement on how to move forward. While I fully agree, my one (accidentally started) communication with the core Python team on my worries surrounding this left me with a bad taste in my mouth. I'll just need to get over that, I know, and I'm sure I put my foot in my mouth in a few places, but when people express their worries they shouldn't be responded to in the way I was responded to. Anyway, you can expect defensive responses from the Python 3000 developers and we'll need to get past that. It may be difficult to get more unified support from the light framework project leadership since porting these frameworks will take less time. In any case, I believe this dialog likely needs to come sooner rather than later, particularly from the leadership of the framework projects. I am not sure if some of this at least occurring informally, but I get a sense that formal discussion with the python team is needed soon and well before P3K is ready. It would at least provide some sense of how we will be navigating inevitable changes to the language (and to determine impacts on the zope framework and our own development decisions). With a plan and some consideration by the python team, the objectives of P3K may not seem so bad. You're making very good points. We should indeed come up with a strategy to approach the leaderships of other web frameworks and large libraries, to see whether we can get a common communication channel going, to which we should invite the core developers. David, could you take the lead on this? I think we need to come up with an announcement inviting people, a mailing list, and a wiki, to start with. I'd be happy to help with this, but we need someone else to take the lead (my reputation with the core developers has been damaged by the previous fracas anyway). I can coordinate this effort with the Zope Foundation board should it be needed. The best initial strategy, I think, would be to approach some individual figures within these communities privately to gauge their interest and see whether we can come up with a joint position of some kind. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev
Re: [Zope3-dev] Re: What does python 3000 mean for zope?
Hi Reinoud. I started the thread since I am concerned there could be a real threat to zope that I work with. I have not seen anything on the python list in general but I was happy to see the blog article from Twisted to get some perspective from Glyph. Without an effort to assess and plan with the folks who's libraries we depend upon (and those that depend on zope) there could be harsh implications. I have no doubt the proposed language changes will be good for the maturation of python, but no backwards compatibility means we are building obsolescence with each line of code we write. The threat to substantial and established projects like Zope and Twisted is fracturing the community, forking the projects, and creating a marketing environment for python 2 technology that could make it a difficult sell. Python 2 to P3K will require substantial rewriting from what we are seeing and I think we all agree we cannot put much stock in conversion scripts for complex code with subtle language changes. The fact that that Jean-Paul Calderone is involved with this is at least a bit more comforting understanding his ties to Twisted. I was hoping Jim might respond to this thread since I am certain there is concern about what this means for the future of Zope. I am hoping that core communities of python framework developers may come together on what is in their best interests. Communication with the core python team on impacts could create a cohesive strategy for the future and improve buy-in if there can be agreement on how to move forward. It may be difficult to get more unified support from the light framework project leadership since porting these frameworks will take less time. In any case, I believe this dialog likely needs to come sooner rather than later, particularly from the leadership of the framework projects. I am not sure if some of this at least occurring informally, but I get a sense that formal discussion with the python team is needed soon and well before P3K is ready. It would at least provide some sense of how we will be navigating inevitable changes to the language (and to determine impacts on the zope framework and our own development decisions). With a plan and some consideration by the python team, the objectives of P3K may not seem so bad. Regards, David Reinoud van Leeuwen wrote: On Tue, Sep 11, 2007 at 10:29:58AM +0200, Martijn Faassen wrote: Paul Winkler wrote: On Sun, Sep 09, 2007 at 05:39:45PM +0100, Martin Aspeli wrote: Has there been a strong statement that there won't be a Python 2.7 and beyond? Will Python 2.x be actively killed off? Quite the opposite, Guido proposed last year to do 2.7, 2.8, and 2.9. After that it's not clear to me. He must've changed his tune then. I heard him discuss Python 2.6 and maybe Python 2.7, but definitely wanted to avoid anything following this. Do similar discussions like this one exist in the other Python framework communities? I think we are all having the same problem. ___ 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: What does python 3000 mean for zope?
Yes these are all fairly painful scenarios. What's worse is the scenario for organizations evaluating zope end user software using python 2. It's will not be a great selling feature to start with the premise that anything you see today will require major refactoring to give provide a measure of 'futureproof' code. It is also possible that as so long as you are tied to python 2 you may be fighting the impression that you are speeding toward obsolescence. Regardless, I expect this impression to develop outside the python community and formalized as a marketing tool against python applications. This will come into play when it is common knowledge that P3K is stable and virtually all python technology runs on python 2. I can see possible wins here for ruby and java as they will be evaluated without this inherent risk. Porting will have to come soon; otherwise the risk is loose the ability to market zope. Zope is in the fray with other frameworks in python and other languages. Not seeing a zope emerging in P3K (as it is evolving) is likely going to mean a challenging sell for anyone getting involved with the framework (whether you are a developer or consumer). Consumers need to know their data will survive this potential (think about all those pickles). A zope 4 on P3K could be an answer (with zope 3 modules being ported as P3K evolves). It could also signal the beginning of coordination efforts with other projects that zope depends upon (and provide a sense of collaboration to address the future). The ZODB would have to be a priority for this. It's ugly, but I think moving through a python 2.5 and then a 2.6 without establishing a parallel track may be perilous. This sort of activity would mean meeting P3K as opposed to inviting the consequences. Personally, relying on conversion scripts from a 2.6 release is not comforting. Subtle changes in the language are already being discussed and it will not solve the issue of extensions that has already been raised. P3K has the potential to disrupt zope and its marketing unless there is a means of handling this through planning (with stakeholders whose code is used in zope). The similarity of P3K to Y2K gives me some doubt that the branding 'Python 3000' will be seen as the best. I likely won't be the last to draw this similarity and the potential for P3K to put major python projects like zope in turmoil for years. Regards David Martijn Faassen wrote: Stephan Richter wrote: On Saturday 01 September 2007 15:33, Martijn Faassen wrote: I think Zope will be on Python 2.x for many years to come. I really hope not. A friend of mine and I want to get a bit involved in Python 3000 once it is stable enough that the standard libs can get some attention. At this point I really want to have an initial look at porting Zope 3 packages to Python 3. I really hope we can move to Python 3 in a reasonable amount of time. Zope 2 is using Zope 3. This means we have some choices: * upgrade Zope 3 to Python 3 and upgrade Zope 2 to Python 3 too. I suspect especially the latter will be very difficult. Let's go port Plone! * upgrade Zope 3 to Python 3 and leave Zope 2 behind on an older version of Zope 3. We better come up with a damn good explanation to the community on this one. * upgrade Zope 3 to Python 3, maintain a Python 2 version too in parallel for Zope 2 to use. A maintenance nightmare in my opinion. * fork Zope 3. You'll have one version which runs on Python 3, and another version which runs on Python 2. People pick their sides and Zope starts diverging. A terrible mess we should avoid at all costs in my opinion. Note that without Zope 2, you'll still have to worry about other things that depend on Zope 3, and things that Zope 3 depends on. A lot of people will need to coordinate quite intensively. Anyway, ignoring Zope 2 and any dependencies, I suspect the porting of Zope 3 to Python 3 will be hard enough by itself to take a long time. Here is where I hope to be pleasantly surprised by better than expected tools. You mention moving to Python 3 in a reasonable amount of time. You don't mention what you consider reasonable. I consider it unreasonable to expect a transition within the next 2 years. I also consider 2 years a very optimistic timeframe by the way, as that will be only 1 year after the release of Python 3 and there will be a lot of dust to settle first. At the very least, we should all agree we will port to Python 2.6 *first*. This is the version of Python that is supposed to work with the 2to3 conversion script. This is the version of Python that will, hopefully, already introduce the bytes type (the using of which should help the conversion script tremendously) and other bits of Python 3. I'm afraid you and your friend are either asking for a lot of work and trouble, or will have to wait for a long time until Zope will start making use of any changes you make to the Python
Re: [Zope3-dev] Re: What does python 3000 mean for zope?
Hi Andreas. Yes, this is where my thoughts were going with this in the short and medium term. If you extrapolate this to not only zope, but to other folks that depend upon zope's code base, and to the code zope depends upon, this is not a good scenario. I am thinking about twisted, lxml, and many other code bases and packages. Each project will make a decision of what to do and when - and I think ultimately you will get into a situation of supporting both 2.X and 3.X users at the same time. The timing of when one project moves forward will most likely not be coordinated with other projects. The ability to use help like the GSoC for making such transitions may also be held back if there code in other repositories that is not yet ready. One thing though is certain and encouraging. There is definitely an advantage with zope's packages and eggs. I'd have to say Jim's foresight and zope's packaging story will have prepared it well for the future. I can not imagine what this could look like if the code was where it was a year or two ago. Despite this, zope is not an island. But what of the projects that only have in the short term the capability to go one way or the other due to limited resources. For large projects and frameworks, it may be possible to maintain a 2.x and a 3.x. Regardless, it will ultimately require more human resources and splitting mind share between two sets of consumers. Ultimately, the folks that will even want to maintain a 2.x code base will quickly erode since the forefront of development is never the past. Perhaps it will all move more quickly for this reason when python 3K is out for real. Regards, David Andreas Jung wrote: --On 1. September 2007 16:33:58 +0530 Baiju M [EMAIL PROTECTED] wrote: Andreas Jung wrote: --On 1. September 2007 16:00:19 +0530 Baiju M [EMAIL PROTECTED] wrote: May be we can try Python 3.0 porting in next GSoC ? :) -1 on that. I am pretty sure that this will lead to two different codebases which are hard to maintain over long period of time. We should stick with Python 2.X for the time being. Otherwise we risk compatibility issues with the current deployed Zope installations. We must not jump on every train just because it stop in front of out door. I hope your -1 is for porting to Python 3.0 in next year itself. May be we should consider it after Python 3.0 final release ? Otherwise how long will be the time being ? If packages like ZODB, zope.interface zope.component is not ported that will be great loss for Python 3.0 programmers. I am basically speaking here for the Zope 2 world. If we move core components to Python 3000 we have to move the complete Zope 2 core to Python 3000 which will cause a huge disaster because of almost every third party component is likely to break. This is a big risk for the reputation of Zope. I currently don't see how a smooth transition would look like. At the end will have Zope 2 for Python 2.X, Zope 2 for Python 3.X and Zope 3-ish components for Python 2.X and different components for Python 3.X...appears as a nightmare to me. Andreas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] What does python 3000 mean for zope?
Hi. I am concerned about the announcement of python 3000 today that will break backwards compatibility. Zope and twisted are my favorite frameworks. The code base for both frameworks are not small. I haven't evaluated the changes but I can say this is a not great day for the python community either. I can see this dividing folks between present and future. Particularly, I'm thinking about incompatibilities developing around packages and dependencies through some sort of drawn out transition by the python community that may take years. Has anyone thoughts or comments about python 3000 implications for zope? Unfortunately, my first thoughts are that Python 3000 feels like Y2K for python :-(. Many thanks. Regards, David ___ 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: [StabilizeEggPackages] (edit) Is that all that has to be done in setup.py?
I have been following this approach with the long descriptions for my package descriptions and believe it it a consistent and meaningful way of communicating to a developer. It is not enough for me to see a couple of paragraphs. The doctest text inclusion gives me an immediate answer to what the package is about and how it works. I like what has been done very much and would like it to continue this way. Many thanks. Regards, David Benji York wrote: Christian Theune wrote: Am Mittwoch, den 29.08.2007, 09:58 -0400 schrieb Fred Drake: I really don't like long PyPI pages myself; a few paragraphs seems sufficient, and is certainly more in line with the original intent of the long description field. Since you asked: I like it (in absence of better project web pages). IMHO This issue doesn't have to be dealt with for the initial stable release. My highest interest is getting the stable software out of the door in a timely manner. The more we add to the TODO list for each package the longer it's going to take. +1 ___ 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: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
Hi. I've tended to use system python against some better advice, but use but leave it clean since I am using buildouts. This really has had more to do with the convenience of using the system package tools for upgrading such as FreeBSD ports system. I've also been experimenting with CentOS and Fedora Core - so here yum comes into play. I think the best advice I have got from the discussion seems to be using a hand compliled python. I am almost at a point of thinking perhaps it my be best to use cmmi recipe for most system software on a stripped down server. I already need to patch a compiler and lxml will also only run on most up-to-date xml libraries so building these seems to make sense to make sure it does not choke. The number of system packages I really need is limited and I am beginning to see more complex buildouts for apache for its configuration also: http://svn.thomas-lotze.de/public/buildout-recipes/apache Custom recipes are reasonable to assemble. Has anyone any opinion on whether these are sane thoughts. On the plus side having complete control on a minimal software situation on a stripped server is attractive. On the other side the convenience of ports packages or yum are quite nice but potentially bring in other software you don't want or could potentially break a production setup. Updates and patches are certainly possible with buildout. Is this taking things too far in practice? I see ruby's Capistrano doing much of the same jobs as zc.buildout - perhaps it has been around longer - but at the same time most setups I see still involve initial system software setup using yum with Capistrano doing the rest. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
One form demo might be a simple form that relates the input from one field to another in the form. For example two dropdown lists where second dropdown is based on what choice in first dropdown. The need for something like this is fairly common for apps I believe. Regards David Stephan Richter wrote: On Wednesday 30 May 2007 12:27, David Pratt wrote: Another form related demo might show how to effectively use a data source with a large number of choices in a select list (like choosing a user in a select list from all users on the site) using an ajax widget where you can start typing and it will begin narrowing the choices - much like the way live search works (and without generating all options in the form). Yeah, there are some demos related to AJAX-features that could be done. Roger is already working on AJAX-related demos, including live search and input validation. Regards, Stephan ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] rpm support for buildout
Hi Jim. That's great. If there is anything I can try, I am happy to test it out. Many thanks. Regards, David Jim Fulton wrote: We've been making RPMs using buildout for our internal hosted projects. I'm working on a sample RPM with detailed documentation. I expect to have this done soon. Jim On May 16, 2007, at 11:39 PM, David Pratt wrote: Hi. I recall Jim indicating that a buildout might be available demonstrating the generation of an rpm. Is anyone aware of whether anything is available to demonstrate this. Many thanks. -- Jim Fultonmailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporationhttp://www.zope.comhttp://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] rpm support for buildout
Hi. I recall Jim indicating that a buildout might be available demonstrating the generation of an rpm. Is anyone aware of whether anything is available to demonstrate this. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Martijn Pieters wrote: On 5/8/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I know there must be a few folks that would like to easily add other clients or servers to zope (at or after bootstrapping) and have control over the services with the running reactor :-) A simple api for accessing the multiservice after bootstrapping would make zope more accessible to twisted development. I'll say it again: I have had no need to access the multiservice. A multiservice is nothing but a container that makes it convenient to start and stop multiple services. The services themselves directly contact the reactor, they do not depend on a multiservice for this. The reactor is a singleton, you can import it yourself too to access it's API if you need it's services. Hi Martijn. Thanks again for your reply. I do understand the multiservice, however I feel is a shame that configure information in my zope.conf for any of the built-in server types would not result in my having control over these services following bootstrapping. It does not need to be this way. :-( In my case, I subclassed ZopeTCPServer, but that's a subclass of twisted.application.internet.TCPServer, and all it adds is a hook to log the service startup in the event log. I also use a dedicated threadpool of 1 thread for the debug server, but that's a application requirement, services use the reactor threadpool directly otherwise. Just hold onto the services you create, and start and stop them at will directly. Subscribe to the Zope ProcessStarting event to start your services at Zope startup time, and use the twisted reactor system event triggers to hook into the shutdown. You could even create your own multiservice object to manage your own services in one go. I acknowledge that this is not a prerequisite to twisted development in zope. I am working with twisted as it is. My apologies if it seems that I have communicated it this way. It would add convenience to facilitate methods on the services in a single service container for the instance as a whole. I should be able to obtain from my instance what services it is currently running, give me an iterator of the services, check the status of any service generally, start this service, stop that service, add this one or drop that other one. This is better in my view - it would also provide simple infrastructure for integration for applications. I have written clients and servers in twisted, the main difference being that I am configuring in zope.conf and constucting buildouts to automate this configuration. I want twisted and zope to be better partners for applications. At the present time, I am adding some additional twisted functionality to zope as opposed to simply adding another service to my application - in way where the control of services for the instance is managed centrally. This is how an application should work and how it could work. Perhaps the best way to do this is an api since I will not be the first or last person to want to build applications with multiple services that you will want to control and monitor. I believe a services api could provide this more generally - whether a zope application uses zserver or other server flavor for that matter. At the present time services cannot be assembled concretely with central control in an application which is disappointing to me. I guess thats what my experience is telling me about this - though I am more focused on using twisted in zope. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Martijn Pieters wrote: On 5/8/07, David Pratt [EMAIL PROTECTED] wrote: Hi Martijn. Thanks again for your reply. I do understand the multiservice, however I feel is a shame that configure information in my zope.conf for any of the built-in server types would not result in my having control over these services following bootstrapping. It does not need to be this way. :-( Right, it seems I misunderstood. You want to be able to control services not created by you, but by the existing codebase in zope.app.twisted. That is a very legit usecase. :) Hi Martijn. Yes, in fact I would like want control over all services in the app but it is currently impossible the way it is now without some hacking. I don't want to do that. I hadn't thought of that angle, this sounds like something worthy of putting into the Zope3 bugtracker. Registering the multiservice as a utility would solve this usecase. I'll put this in the bugtracker as you have suggested. I think this would be a good short term solution. A better long term solution being a services API that could be used generically. There was some talk of using paste for configuring servers so at the least I am hoping that when this is considered that controlling services within zope be given a fair chance also. Services should be able to be turned on and off using application logic - and the app itself should be able to tell you something about its services and their state. I acknowledge that this is not a prerequisite to twisted development in zope. I am working with twisted as it is. My apologies if it seems that I have communicated it this way. It would add convenience to facilitate methods on the services in a single service container for the instance as a whole. I should be able to obtain from my instance what services it is currently running, give me an iterator of the services, check the status of any service generally, start this service, stop that service, add this one or drop that other one. This is better in my view - it would also provide simple infrastructure for integration for applications. Right, access to the multiservice would give you that, it is an iterator. For sure. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Martijn Pieters wrote: On 5/8/07, David Pratt [EMAIL PROTECTED] wrote: A better long term solution being a services API that could be used generically. There was some talk of using paste for configuring servers so at the least I am hoping that when this is considered that controlling services within zope be given a fair chance also. Services should be able to be turned on and off using application logic - and the app itself should be able to tell you something about its services and their state. For which you'd need to expose the root multiservice to start with, of course. Yes, absolutely :-) Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Hi. I know there must be a few folks that would like to easily add other clients or servers to zope (at or after bootstrapping) and have control over the services with the running reactor :-) A simple api for accessing the multiservice after bootstrapping would make zope more accessible to twisted development. Has anyone got any ideas on incorporating this. I have made a suggestion but hoping for input and other ideas to make this happen. The ZopeService class subclasses service.Multiservice. The Multiservice itself provides methods from twisted for adding, disowning, starting or stopping services or iterating over the services in the multiservice. I am hoping we can can come up with a good way to make this object accessible within zope. Many thanks. Regards, David David Pratt wrote: I am wondering if as part of bootstrapping zope, that a utility could not be set up in the site manager that could hang on the zope multiservice object. Methods available for the utility could allow you access to this after booting zope. Is this reasonable? Many thanks. Regards, David David Pratt wrote: Hi Martijn. Many thanks for your reply. I was not aware of your project so it is quite nice to see. I am hoping to try it out. :-) At zope's startup, a multiservice is started that currently adds the servers setup in the zope.conf. I have created configuration for additional clients and servers to use the existing thread pool and currently adding them to the multiservice using a modified main.py By having access to the multiservice object, you have complete control of each service in the app as well as the ability to incorporate other services to an already running reactor. Interaction within the app using multiple reactors is not safe - so access to this object allows you to add, remove, start or stop services. I also want the configuration to be explicit - so to using zconfig and recipes. Overall, I am integrating apps into buildouts as well. It is useful to be explicit here too since your configuration will otherwise be in a single egg somewhere. This could make it awkward to run multiple servers performing the same task on a machine, which is the pattern I am working with. Regards, David Martijn Pieters wrote: On 5/3/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. I am not sure what you are looking for, but I have no trouble starting additional services after Zope startup. See my Wing IDE integration for Zope3, for example; http://trac.zopatista.com/zopatista/browser/z3wingdbg/trunk/ It starts additional services, such as a single-threaded HTTP debug server on a separate port, either at Zope start or later as the user requests. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] tracking satellite project's trunks
Hi Fred. I like this very much too :-) If you want your product to sing, you can include sing packages, if you want it to dance, you can include dance packages. What's more, is that most python projects are moving to egg distribution, if not there already. Besides eggs, wsgi is allowing many more things to occur on an app level overall. Overall, these developments create some very interesting and exciting potential to mix and match functionality without the constraints of a particular framework. Regards, David Fred Drake wrote: On 5/4/07, Christian Theune [EMAIL PROTECTED] wrote: Right. In the last days I felt like in the future we should spend some quality time (maybe face to face at a conference or sprint) to review what happened to the way people work with Zope and how we define it. I think what's happened is something very simple, inevitable, and reasonable: We've stopped working on Zope 3 and moved to working on our applications. This changes how we think about the place of Zope 3 in our work more than anything else. It's no longer a product itself, but a means to an end. This is what we intended from the beginning, but the shape we predicted for the result was more similar to Zope 2 than has turned out to be useful. The move to separate satellite projects is really a move from using an all-singing, all-dancing framework for all applications to using different sets of libraries for each application based on what's needed for the application. I think this is a good thing. -Fred ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
I am wondering if as part of bootstrapping zope, that a utility could not be set up in the site manager that could hang on the zope multiservice object. Methods available for the utility could allow you access to this after booting zope. Is this reasonable? Many thanks. Regards, David David Pratt wrote: Hi Martijn. Many thanks for your reply. I was not aware of your project so it is quite nice to see. I am hoping to try it out. :-) At zope's startup, a multiservice is started that currently adds the servers setup in the zope.conf. I have created configuration for additional clients and servers to use the existing thread pool and currently adding them to the multiservice using a modified main.py By having access to the multiservice object, you have complete control of each service in the app as well as the ability to incorporate other services to an already running reactor. Interaction within the app using multiple reactors is not safe - so access to this object allows you to add, remove, start or stop services. I also want the configuration to be explicit - so to using zconfig and recipes. Overall, I am integrating apps into buildouts as well. It is useful to be explicit here too since your configuration will otherwise be in a single egg somewhere. This could make it awkward to run multiple servers performing the same task on a machine, which is the pattern I am working with. Regards, David Martijn Pieters wrote: On 5/3/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. I am not sure what you are looking for, but I have no trouble starting additional services after Zope startup. See my Wing IDE integration for Zope3, for example; http://trac.zopatista.com/zopatista/browser/z3wingdbg/trunk/ It starts additional services, such as a single-threaded HTTP debug server on a separate port, either at Zope start or later as the user requests. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.twisted.main and zope multiservice
Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. There are use cases for starting and stopping particular services (a short interval) also. An api should be flexible enough to add other clients and servers to the mix. Right now there is no way of getting the multiservice from the current main script. What is needed is a class that could be given this object so that there is a means to access it directly in an app. The multiservice is an important object from the standpoint of being able to start, stop, or add other services to the multiservice (from other packages) even after the main zope startup. A small api for determining what services are part of the multiservice and methods to add or remove services from the running reactor could be added (since these methods are available in twisted). I am hoping by bringing this up that there may be some discussion on how best to accomplish this. I know that Jim has communicated recent interest in a twisted version of ZEO. I share the goal of having a secure transport between clients and servers, however there are many more opportunities for twisted in zope. Being able to access the multiservice is important to this. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main and zope multiservice
Hi Martijn. Many thanks for your reply. I was not aware of your project so it is quite nice to see. I am hoping to try it out. :-) At zope's startup, a multiservice is started that currently adds the servers setup in the zope.conf. I have created configuration for additional clients and servers to use the existing thread pool and currently adding them to the multiservice using a modified main.py By having access to the multiservice object, you have complete control of each service in the app as well as the ability to incorporate other services to an already running reactor. Interaction within the app using multiple reactors is not safe - so access to this object allows you to add, remove, start or stop services. I also want the configuration to be explicit - so to using zconfig and recipes. Overall, I am integrating apps into buildouts as well. It is useful to be explicit here too since your configuration will otherwise be in a single egg somewhere. This could make it awkward to run multiple servers performing the same task on a machine, which is the pattern I am working with. Regards, David Martijn Pieters wrote: On 5/3/07, David Pratt [EMAIL PROTECTED] wrote: Hi. I'm really wanting to do more with twisted in zope. One thing that would make this much easier is to have a means of getting hold of the twisted multiservice following startup as opposed to using a different main.py (as I have been) to allow the other services to be added, started or stopped at, or any time following startup. I am not sure what you are looking for, but I have no trouble starting additional services after Zope startup. See my Wing IDE integration for Zope3, for example; http://trac.zopatista.com/zopatista/browser/z3wingdbg/trunk/ It starts additional services, such as a single-threaded HTTP debug server on a separate port, either at Zope start or later as the user requests. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zc.catalog-1.1.1 egg has gone missing
Ok I see what has happened, a 1.2dev egg was released to pipy and 1.1.1 is now no longer current release and is now inaccessible. Could someone put 1.1.1 on downloads site. Many thanks. Regards, David David Pratt wrote: Something has happened to the tagged zc.catalog egg. It was available earlier to allow my buildouts needing this egg to complete. Getting distribution for zc.catalog==1.1.1 Error: Couldn't find a distribution for zc.catalog==1.1.1. I am beginning to wonder if I should be spending some time on a private cache that only goes out get a copy on if not already in the cache. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zc.catalog-1.1.1 egg has gone missing
While googling to see if anyone has done anything with an egg cache I discovered this capability already existed in the buildout that I did not know was already there - go figure. Thanks Jim :-) http://svn.zope.org/zc.buildout/trunk/src/zc/buildout/downloadcache.txt Here's another package of possible interest to similar minded folks: http://cheeseshop.python.org/pypi/pypicache/0.2 Many thanks. Regards, David David Pratt wrote: Ok I see what has happened, a 1.2dev egg was released to pipy and 1.1.1 is now no longer current release and is now inaccessible. Could someone put 1.1.1 on downloads site. Many thanks. Regards, David David Pratt wrote: Something has happened to the tagged zc.catalog egg. It was available earlier to allow my buildouts needing this egg to complete. Getting distribution for zc.catalog==1.1.1 Error: Couldn't find a distribution for zc.catalog==1.1.1. I am beginning to wonder if I should be spending some time on a private cache that only goes out get a copy on if not already in the cache. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Autoconfiguring a site.zcml
and flexibility at the expense of understanding what you need which can take time. Perhaps the biggest hurdle is that when we are speaking of dependencies, we are talking apples and oranges to some extent - because eggs spell dependencies but it is packages we need to put into our configuration. Overall, it should not matter really as far as I can see. If egg1 needs the contents of egg2, it stands to reason that that package includes of egg2 need to be pushed higher in the site.zcml that those of egg1. Further if we adhere to good information in the egg we should not have to worry that imports of packages in eggs will not work. So I tend to believe that some means of scoring, weighting or boosting could be used together with the exploration of each egg for a configuration (*-configure.zcml, *-meta.zcml) to autogenerate the site.zcml as the buildout proceeds. I see potential to also include (in the app part of the buildout recipe) a simple boolean value to indicate whether your app uses an overrides so it can write an includeOverrides into the site.zcml to point to an overrides.zcml in your app egg as part of the automation. Perhaps something like this could save us poor humans the terrible and ominous fate of ordering all these includes, much of which is based on dependencies spelled out in the eggs already. I don't think we need a gui for this honestly - we just need some logic. In any case, I am certain others will likely arrive at this conclusion with eggs and zope given enough time. It only took me a few days of this to begin to consider whether there has got to be better way that can operate more dynamically on the app (with some better certainty that you have got your bases covered on dependency) given a list of eggs you are using. Many thanks. Regards, David Martijn Faassen wrote: Hello, Tres Seaver wrote: David Pratt wrote: On the basis that eggs spell out dependencies, I am thinking the inclusion of packages and their dependencies should be enough to dictate the sequence of inclusion for package configuration (and creation of the site.zcml) for the app buidout recipe. This could be a option to the current manual configuration. - -1. Configuration is *policy*; implicitly wiring in the default configuration for every egg on the path is not going to be an acceptable default. In the path? David didn't say in the path, did we? What about in the buildout? Since my buildout already says explicitly it wants egg foo, and egg foo needs egg bar, it is a major pain to have to specify the ZCML for bar manually. I don't think something being policy means it's automatically a bad candidate for automation. Information about the policy may after all be elsewhere in the system, for instance in a buildout.cfg. Presumably, the reason folks would use this recipe is to configure one or more of the same app. I know attempting to do this manually is prone to errors if packages are not in the correct sequence or if you miss the configuration of a package. Any thoughts on this. Many thanks. Not necessarily. There are really two kinds of packages in play here: libraryish packages, which supply mechanisms, and applicationish packages, which use the mechanism according to some policy. I would argue that the only things you can safely auto-include would be the 'meta.zcml', because it is policy-free. Reusable packages need to avoid imposing policy (they may *suggest* it, but they shouldn't insist). That's where we have the concept of overridable defaults. So the default should be to follow the suggestions, and there should be an option in the system to override this suggestion. I would cheer if somebody proposed writing a UI which introspcts packgaes for such suggestions, and allows the site manager to merge / override them to create an appropriate 'site.zcml'. Until then, I don't want package authors dictating to site managers. Who are these ZCML-using site managers you are speaking of? Anyway, are you saying you want some form of ZCML UI to be created before *any* automation can be implemented? Asking for the creation of a UI on the Zope 3 mailing list is paramount to waiting forever... If you never automate policy, you'll be writing a lot of stuff by hand. That may be fine for you, but I myself would prefer to write less boring code and focus on more interesting problems. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Getting 403 error from download.zope.org
Any idea what is happening with the site? Getting distribution for zope.app.zptpage Error: Can't download http://download.zope.org/distribution/zope.app.zptpage-3.4.0a1.tar.gz: 403 Forbidden Many thanks, Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Autoconfiguring a site.zcml
On the basis that eggs spell out dependencies, I am thinking the inclusion of packages and their dependencies should be enough to dictate the sequence of inclusion for package configuration (and creation of the site.zcml) for the app buidout recipe. This could be a option to the current manual configuration. Presumably, the reason folks would use this recipe is to configure one or more of the same app. I know attempting to do this manually is prone to errors if packages are not in the correct sequence or if you miss the configuration of a package. Any thoughts on this. Many thanks. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.widget(.tiny) widget available to easy_install anywhere?
Hi Martin. Cheeseshop does this already. You can see how a nice overview page is constructed by putting readme.txt with readme.txt release notes in setup.py as restructured text. This is available on some zope packages but also the zif packages on pipy. See zif.headincludes in the cheeseshop as an example of how this works for a nice web page explaining the package. I am not sure why there are two resources for obtaining eggs myself, not sure if it is because pipy gets busy. Should the default be pipy or will this slow buildouts? Maybe all packages could be put there in any case even if primary dependency link for zope packages is download.zope.org. Maybe this just adds to the headache of releases to have more than a single location. pipy already has the infrastructure for some proper searching and management for package maintainers - so not sure that the wheel needs to be invented. Actually, I thought the way this was all going to unfold was with the ZF website which I think is still being worked on. Many thanks. Regards, David Martijn Faassen wrote: Hi there, I'm interested in adding a dependency on z3c.widget, and in particular z3c.widget.tiny, in an application I'm available. In the svn checkins I see a comment by dobe saying: buildout and egg, clean imports This implies to me there might be an tgz that buildout/easy_install can use available somewhere. But where? I cannot find it in the cheeseshop, nor in download.zope.org/distribution. Is it available somewhere else? Or should I upload a version of it myself? Regards, Martijn P.S. Visibility of Zope 3 extensions would be increased greatly if we could have an overview page per extension on zope.org somewhere. It would of course include the canonical download link as well. I think we can accomplish this relatively quickly with a fairly low-tech project, but we need a volunteer. Anyone? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.pluggableauth missing from download.zope.org
Hi, my recent buildout is not picking up pluggableauth. Looks like it got missed on download.zope.org. I took a look and it's not in the listing. Can someone put the egg there please. Many thanks. Getting distribution for zope.app.pluggableauth Error: Couldn't find a distribution for zope.app.pluggableauth. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.pluggableauth missing from download.zope.org
It's all good. I can live without it. Thanks Gary for the help just the same. Regards, David. Gary Poster wrote: (Resending--sorry David, meant to go to list) Huh. Just a thought, but I'm reasonably sure pluggableauth is effectively deprecated, replaced by zope.app.authentication. What's depending on this? Is my memory or understanding faulty about this? Gary On Apr 19, 2007, at 8:45 PM, David Pratt wrote: Hi, my recent buildout is not picking up pluggableauth. Looks like it got missed on download.zope.org. I took a look and it's not in the listing. Can someone put the egg there please. Many thanks. Getting distribution for zope.app.pluggableauth Error: Couldn't find a distribution for zope.app.pluggableauth. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/gary%40zope.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.viewlet breaking buildout?
Hi. I have already managed to repackage a couple of apps using eggs only zope (zc.zope3recipes on svn.zope.org). Yesterday, I began creating another eggs-only application as a test however this app requires z3c.viewlet. The z3c.viewlet package has a dependency upon zope.viewlet. When running the buildout stopped during the zope egg installation. I deleted the zope.viewlet egg and reran the buildout and it stopped at the same point. Hoping someone can advise if this a possible problem with zope.viewlet or how I might debug this a bit more to complete the buildout. Many thanks. Regards, David The error in the buildout is as follows: buildout: Installing testapp zc.buildout.easy_install: Getting new distribution for zope.viewlet zc.buildout.easy_install: Got zope.viewlet 3.4dev-r73833 Couldn't find index page for 'PILwoTk' (maybe misspelled?) zc.buildout.easy_install: Getting new distribution for PILwoTk While: Installing testapp Getting distribution for PILwoTk Error: Couldn't find a distribution for PILwoTk. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
I'll be happy to see the complete eggification - the sooner the better. The only issue I see as a possible negative is that it may be hard for folks to visualize z3's potential. AFAIK the framework approach has not negatively impacted Twisted that has some documentation and a book but no core app. The pattern for package construction in z3 is getting clearer all the time but folks will certainly need to work to see z3's advantages. Maintaining an eggified app, whether folks want to build on it or learn from it, is likely still relevant to the future of z3. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
