Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
Baiju M wrote: I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. I wonder why zope.dottedname isn't being used here either? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch:
Martijn Faassen wrote: I think we can only make the correct determination if we get an idea of the performance implications. If it turns out the C code brings significant speedups in real-world applications, we should create a zope.hookable with a Python + C implementation. Even if it does bring significant speedups, why does it need to be a seperate package? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] non-zodb persistent registries
Hey Tres, Tres Seaver wrote: 2. Move the persistent registry stuff out into another package, including whatever support is needed to allow for people to migrate existing persistent references. Effectively, this moves one extra out to a package, *including* its testing dependencies. zope.persistentregistry (BIKESHED NAMING ALERT) depends on: - zope.configuration - ZODB3 I was interested to see this for the reason I gave in the subject line, and it might affect the naming of this package... Might I suggest zope.zodbregistry for this? The reason being that, for a long time, I've wanted to see a persistent registry that stored in a rdb rather than zodb. However, I'm a bit stumped at how to implement this and certainly having the zodb-based registry mixed in with the zope.component code confused the hell out of me when I last looked. The one that particularly got me was how, in a multi-process/multi-thread setup such as a wsgi app, you would get other threads'/processes' registries to update themselves when a registry in one thread/process was changed. Any ideas how to do this? We do actually have this problem with the text-file based registry, it's just that we accept a restart of the server is needed when that text file changes. A nice to have would be an equivalent of apache's reload command. Is anyone else interested in this kind of stuff? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 18:03:17 schrieb Lennart Regebro: On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com wrote: Note that the Zope Steering group is not about packages that are not in the framework, so if lovely.remotetask isn't there, it can say little. Which is exactly my point. It surely isn't at the moment, and I don't see that it should be any time soon. What Hermann suggested is somebody that keeps track of all Zope software modules and tells him which is good and which is bad. That's not what you suggested, and as mention, I don't think it's even possible, and definitely not a good idea. Well, yes and no: My idea is that there will be a well-defined set of core packages, and probably some extra packages that are also embraced (e.g. maybe z3c packages, e.g. z3c.form). Of course, trying to embrace every zope package out there will not work. But I think it will make sense to embrace packages that cover a common usecase, for instance, creating remote tasks is nothing uncommon and will be needed by many people. Therefore I'd suggest to embrace at least one package that covers that functionality (e.g. lovely.remotetaks, or zc.async, or something else). For all other packages, it will make sense to create some infrastructure, as stated in another mail of Martijn. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 17:48:37 schrieb Martijn Faassen: Hi there, Lennart Regebro wrote: [snip] And it is in any case in no way even remotely connected to the group Martijn proposed and has been discussed in this thread. - Attracting newbies to web development is not a task of the Zope Framework project directly, and here I diverge from Hermann. That's a task of the Plone project or the Grok project, etc. I do think that the Zope Framework leadership could be much better at attracting and stimulating contributions to the libraries. Attracting more users is important, but that's a task for the Zope 3 app server developers (however they organize) or the Grok project. The Zope Framework is a second-level provider to these projects, and in reality of course people who care about these projects will do most of the driving of development of the Zope Framework. It's a forum where all users of these libraries (many or just a few) can get together, work out our diverse interests, and coordinate. Ok, it seems I mixed up the Zope3 app server and the Zope Framework a little.So, I agree that attracting newbies should better be done via Grok/Zope3 app server or anything else that build on top of the Zope Framework, as this is the logic path. Nevertheless the Zope Framework should have: - Documentation - Central Website - Some other structure for collaboration (mailing list...) And I think that these points should also be a topic of the steering group. I think an ideal approach would be that the above can be seamingless integrated in upper-level frameworks, so that the step from Zope3 app server/Grok to the Zope Framework is as easy as possible, and, moreover, that efforts need not to be doubled (e.g. that someone writing documentation for Zope 3 app server has to write something about interfaces or the component architecture). Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 19:00:12 schrieb Baiju M: On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen faas...@startifact.com wrote: [snip] The steering group isn't intended to take a responsibility for the entirety of the Zope software. Zope 2, Grok and the Zope 3 app server (which would be a distinct entity) would manage themselves and the Zope Framework steering group would not have a say over the libraries and configuration they add. [snip] I do also think that we should go to a smaller set of libraries. We currently share a huge amount of code that only one consumer actually uses. For instance, I think all of the zope.app.* packages which contain ZMI code can eventually be left to the management of the Zope 3 developers, meaning they'd not be part of the Zope Framework anymore. [snip] As a service to the users of the Zope Framework, the Zope developers also make available lists of version numbers of core libraries that have been tested to work together as a Known Good Set. This receives a version number and is the Zope Framework release. Users of the Zope framework can use this list, but may also diverge from it where they see fit. Other projects (such as the Zope 3 application server and the Grok project) also have a Known Good Sets that expand on the Zope framework list (and may diverge from it). Each of these consumer projects can of course have their own release process, schedule and version numbering. [snip] It may very well be true that in some time we'll develop clusters of libraries that can be more or less managed on their own. The ZMI is such a cluster that I hope will eventually emerge (and that the Zope Framework Steering Group doesn't care about directly). That'd reduce the coordination overhead. But sometimes we do need to take coordinated action, and I don't see that need disappearing entirely. I think those who care about Zope 3 (framework/app server/libraries/ or whatever) should form a team and mailing list to discuss about the future development. All other major consumers of the Zope Framework Project has their on mailing list for discussions. I guess very soon zope-dev list will become inappropriate to discuss about Zope 3. Just like Grok,Repoze etc. it is better to create a list for Zope 3, may be re-activate zope3-dev list to discuss about the Zope 3 (framework/app server/libraries/ or whatever). Well, if no one cares about Zope 3, let's leave it. What would be interesting to know is: - Who is out there - What these people are using: * Zope libraries * Zope 2 * Zope 3 app server * Plone * Grok * Something else - Who has already contributed (and what) - Who has the technical expertise and time to contribute This probably would help us/the steering group to form teams around different projects. For instance, as the steering group is not about the Zope 3 app server, there needs to be some team for that part. And I am personally interested if the Zope 3 app server is something that's dying in favour for other projects (Plone/Grok) or is actively used. Best Regards Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Wed Mar 4 12:00:00 2009 UTC to Thu Mar 5 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Mar 4 20:25:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011229.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Mar 4 20:27:34 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011230.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Wed Mar 4 20:29:34 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011231.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Wed Mar 4 20:31:34 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011232.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed Mar 4 20:33:35 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011233.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Wed Mar 4 20:35:35 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011234.html ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] [labo] Disparition de nss3-1 nss3-2
Pour rappel il existait nss3-{1,2,3] pour tester les corrections de
bugs en 3.4 et 3.5. Comme nous développons plus la 3.4 (et que j'ai
besoin de machines), j'ai récupéré les deux premières.
--
Sebastien Douche sdou...@gmail.com
___
Zope-Dev maillist - Zope-Dev@zope.org
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 )
Re: [Zope-dev] [labo] Disparition de nss3-1 nss3-2
On Thu, Mar 5, 2009 at 13:53, Sebastien Douche sdou...@gmail.com wrote: Sorry, wrong ml :( -- Sebastien Douche sdou...@gmail.com ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Standard request/response API
On Mar 1, 2009, at 1:00 PM, Jim Fulton wrote: There's been some discussion recently about separating the interfaces in zope.publisher from the implementations to facilitate other implementations. I think it would be great to standardize request and response APIs. I'd love to see this extend beyond the Zope community. I believe that there have been some moves to try to do this at the WSGI level, although I haven't kept up with the discussion. Speaking for myself, I'd be happy to change my code to comform to a python-standard request API assuming that it had enough in it to adapt it to existing APIs. This might be an excellent project for PyCon. Hey. I have some other projects to work on there as well, but I'll be at PyCon, and am interested in helping on this (specifically the WebOb idea already discussed). Gary ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Zope 3 app server dying? (was Re: the Zope Framework project)
On Mar 5, 2009, at 6:38 AM, Hermann Himmelbauer wrote: And I am personally interested if the Zope 3 app server is something that's dying in favour for other projects (Plone/Grok) or is actively used. Not clear on what you mean by the app server. If you mean zope.publisher, no, I don't think it is dying. The proposals to learn from repoze's approach, and hopefully integrate with WebOb, mean that this is alive and kicking. Also, to varying degrees, some medium-to-big companies are sitting on top of it, and these companies IME tend to have big code bases that tend to change decisions like this slowly. Also, I'm pretty sure Grok also sits on top of much of the publisher machinery. On the other hand, I personally have the impression that the basic Zope 3 ZMI is pretty much dying or dead. Grok and Plone are the only ones innovating in that space (in extremely different ways, of course), as far as I can tell. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: On Thu, Mar 5, 2009 at 11:26 AM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( ImportError: Module %s has no global %s % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Stephan added that code in revision 29143, four years ago now. He actually added the deprecation framework in that same revision. I would rip it out and see what warnings happen during a big test run: suppressing them doesn't look like a good plan to me. How to run these kind of big test run now-a-days, any pointer ? The 'compattest' suff which the sprinters added last month would be a place to start: it runs the tests for dependency packages using your locally modified package. Res. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com 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 iD8DBQFJr9DP+gerLs4ltQ4RAh2FAKCtQApmiKTUPQDWHIIlblpYWfocMQCeI8LP VxJrdbgAlOOWgknn+tGYKE0= =LjBv -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
On Wed, Mar 4, 2009 at 6:36 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Baiju M wrote: On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev nad...@gmail.com wrote: 2009/3/2 Tres Seaver tsea...@palladion.com: -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. I just reverted the change, however, I don't think that the slug files are useful anymore. I cannot see similar slugs in other packages either. Agreed. I don't understand Tres's or Benji's point either; thanks to buildout we've left such slugs long behind us I thought. Typically people would symlink these into an old old installation of Zope 3 (or copy them over). Explicit granular configuration isn't broken at all; if you want to explicitly include zope.file, you include its configure.zcml, not its zope.file-configure.zcml. Unless Tres comes back with some convincing explanation soon, please do get rid of this stuff. Those files exist to allow for a use case we may have abandoned, which is allowing packages to be installed in such a way that a tool could help users enable / disable their configurations, without mutating something like 'site.zcml'. The folks who might have that usecase are those who package zope3 components for deployment outside buildout (as .deb / .rpm, etc.) I don't know if there is such an audience; Benji also pointed out that he thought there were such folks. I don't doubt there are still at least a few, but I also don't think we are supporting that use case very well moving forward. We just need to make an explicit decision to drop support, and then we can remove the slug files. My initial reaction to Dan's removal was that the checkin message (remove zpkg stuff) had nothing to do with that particular change: 'zpkg' was entirely separate from slugs. Same here. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Zope 3 app server dying? (was Re: the Zope Framework project)
On Thu, Mar 5, 2009 at 14:15, Gary Poster gary.pos...@gmail.com wrote: On Mar 5, 2009, at 6:38 AM, Hermann Himmelbauer wrote: And I am personally interested if the Zope 3 app server is something that's dying in favour for other projects (Plone/Grok) or is actively used. Not clear on what you mean by the app server. If you mean zope.publisher, no, I don't think it is dying. I guess he means as a separate release. And I think the answer to that also is no. Those who currently use Zope 3 as a platform without basing it on Grok or Repoze.bfg are likely to continue to do so for quite some time, and they need a separate release. I don't think The Zope 3 app server is likely to die any more than the Zope 2 app server. Now, in five years, maybe. But then again, by then we could all have suffered an alien invasion. :-D -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Stripping down zope.component
Hi there, Thanks for the clarifications concerning registries. Does the multiple registry situation mean any changes to the implementation of the ZCML directives at all or will they just work as soon the underlying registry situation is adjusted? Another point is that we need to make sure we have a path for libraries that use zope.component[zcml] to upgrade. They will now need to import zope.componentzcml at the least, but where does that leave zope.persistentregistry? Who needs to depend on this? zope.site or something like that? Anyway, this upgrade path needs to be spelled out clearly in the zope.component CHANGES.txt pointing people in the right direction. We also need to spell it out in this document: http://svn.zope.org/zope3docs/source/migration/34to35.rst (I hope this and related documents will soon move to the 'zopeframework' area) It'd be nice if we could organize some volunteers to check and adjust any dependencies on zope.component that would need to be adjusted. I think that mainly means checking those places that actually rely on zope.component[zcml], but I think the baseregistry refactoring means checking some other places as well. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope3docs - zopeframework?
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 5, 2009, at 08:24 , Christian Theune wrote: As Dan pointed out, some of those documents are a bit more general than Zope Framework, but, then again, they're also more general than Zope 3. So even for that its better to have them in the Zope Framework area than Zope 3. Before anything is moved around please be aware that the zope3docs repository folder is used to rebuild http://docs.zope.org/zope3docs/ on a daily basis. So make sure you don't completely break it since the URL is now known, indexed and used. Thanks for pointing that out. If we moved it could you put a redirect in place that just pointed .../zope3docs to .../zopeframework? I think to get started on the move we could copy the information using svn copy instead of svn move it, so that we don't break the URL until we're ready updating the texts. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote at 2009-3-3 00:36 +0100: ... * how will the community make hard decisions where lots of people disagree? You try to achieve consensus. When you do not, you get the chance that people turn away. ... * who reminds us of necessary tasks and directions we're going into? Beside the reminders, you need people that do the work. For this, at least, these people must be convinced. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] the Zope Framework project
Martin Aspeli wrote at 2009-3-3 17:21 +0900: ... How many times have we gotten bogged down in semantics or naming discussions and killed off the momentum behind something? A clear notion of semantics and well chosen names are important for any project. I would not want momentum resulting in confused semantics and misleading names. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope.publisher
Shane Hathaway wrote: Roger Ineichen wrote: Shane, Can you review and merge this changes into your zope.pipeline branch? I'm going to put zope.pipeline on hold until the PyCon sprints. Jim and I need to discuss it in person; hopefully then I can understand his opposition and the group can decide on the best direction for zope.publisher and zope.app.publication. You should certainly talk to Jim if you think it will help you. But do note that Jim cannot be blocking your work anymore with a veto. In order to get this to be part of the Zope Framework, you'd need to convince the Zope Framework Steering Group, not Jim. I do think it's extremely bad if Jim's opposition can block all of your work on this project, which you were quite enthusiastic about before, for a whole month! This is exactly the sort of situation we want to avoid under our new system. As a Zope Framework Steering Group member I am quite supportive of your work, as reading your code already I have a much better sense of what's going on than I ever did with the standard publishing stack, so you got 1 out of 3 on board already. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
Hi there, Baiju, much thanks for looking into this. I hope we can indeed get rid of this code. I myself have the suspicion that the deprecation system is perhaps a 'false optimum' in most cases. Putting in deprecations tends to be quite a bit of work (as it's a code change), the warnings weren't always very instructive in the past, and we haven't done a good job of removing deprecations over time. Instead it might be better if we use that energy to provide better documentation about changes and what to do in plain text. Code might break where the deprecation system would provide a backwards compatibility warning, but perhaps that's a faster and easier way to get people to update their code. For deprecated import locations I recommend we just put in a backwards compatibility import (no deprecation system) and use a combination of documentation and the enhanced test runner which can report about indirect imports. Perhaps there are other cases where the deprecation system is of use, but I myself am quite inclined to see about ripping it out and see what happens. Tres Seaver wrote: [snip] The 'compattest' suff which the sprinters added last month would be a place to start: it runs the tests for dependency packages using your locally modified package. For more information see here: http://pypi.python.org/pypi/z3c.recipe.compattest If you can't get it to work right for you (it's tricky business to get it set up), or have any other suggestions for improving it, please start a thread here. I'll get the right people to listen. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] deprecating the deprecation system?
Hi there, Perhaps it's time to deprecate the deprecation system. Why? * I've had good experience in the Grok project with just noting changes that might break code in the upgrade notes for Grok and telling people how to fix it. Using documentation more background can be provided and it can become a lot more clear what to do. * using the deprecation system requires quite a bit of effort, as we're adding code. Do we test deprecations? That's quite a bit of energy spent there that we could instead spend on documentation. * it's a zope-specific system no other Python projects use. Now we'll need some of them, but do we need this one? * we've not been very good at removing old deprecations over time. * the deprecation system's messages have traditionally not been of a high quality. I recall occasions where it told me half of what to do, and certainly won't give me any background on what is going on. * for moving code around we have an alternative system: a backwards compatibility import, documentation about what to do, and a tool part of the test runner which can point out indirect imports. I therefore propose we do the following: * look at any package which uses deprecation warnings now. * rip out the deprecation warnings and backwards compatibility code. Even if it's really expiring in 2010 (I doubt we have much of this). When you do so and you think anyone might still using that code path, please make a remark in zope3docs/source/migration/34to35.rst about what's going on and what people are to do. * run the compattests to see whether anything breaks. I think it's quite possible some deprecated code is in use by the Zope libraries themselves. :) Thoughts? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] zope3docs - zopeframework
Hi there, I've moved over the documentation zope3docs over into the zopeframework/trunk package. I left the documentation in zope3docs too for now so as not to break the automated web build system. Jens, could you pick up zopeframework/trunk now for http://docs.zope.org/zopeframework? And put a redirect in place for http://docs.zope.org/zope3docs to the new location? We can then retire zope3docs. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] the Zope Framework Steering Group expands!
On Thu, 2009-03-05 at 16:53 +0100, Martijn Faassen wrote: Hi there, I'm happy to announce that the Zope Framework Steering Group is now bigger than Just Me. Stephan Richter and Christian Theune have now joined the Steering Group, bringing it up to 3 members. I think both don't need much introduction on this mailing list. Since we're now bigger than 1 person we'll have to demonstrate to the skeptics we can reach consensus quickly and clearly! I agree that we should demonstrate that! -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope3docs - zopeframework?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 5, 2009, at 16:32 , Martijn Faassen wrote: Thanks for pointing that out. If we moved it could you put a redirect in place that just pointed .../zope3docs to .../zopeframework? I think to get started on the move we could copy the information using svn copy instead of svn move it, so that we don't break the URL until we're ready updating the texts. Let's do this: - svn copy zope3docs to zopeframework - once you think zopeframework is ready for public viewing, let me know and I'll set up a self-updating sandbox and a redirect - after all that you can safely delete zope3docs in SVN. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmwCswACgkQRAx5nvEhZLIw7wCfYdIyMeo1Bdr0Z96oxzKutrh8 DM0An0bVZyVT0T7C7aXwcD71AQOx0/kv =1wTg -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope3docs - zopeframework?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 5, 2009, at 18:24 , Jens Vagelpohl wrote: Let's do this: - svn copy zope3docs to zopeframework - once you think zopeframework is ready for public viewing, let me know and I'll set up a self-updating sandbox and a redirect - after all that you can safely delete zope3docs in SVN. Just saw your other message, I'll set everything up and answer the other thread then. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmwC3sACgkQRAx5nvEhZLKVqwCeIRgkDTOTAKJVbNTuA/25e9gx pnUAn3WMB/jp0pa06UqwYfAHwxZxznKs =mzhb -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope3docs - zopeframework
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 5, 2009, at 17:55 , Martijn Faassen wrote: Jens, could you pick up zopeframework/trunk now for http://docs.zope.org/zopeframework? And put a redirect in place for http://docs.zope.org/zope3docs to the new location? We can then retire zope3docs. All done. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmwDacACgkQRAx5nvEhZLLqUACcCkhlCDTlnMNufD3wbKoRH+TU nW8AniiZCJUhQJC6DI+d9Bxwu/h7jHE1 =j7VO -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Proposals: more refactoring
I'd like to continue moving code to saner places, so here's two more little ideas on next refactorings: - Move password managers from zope.app.authentication to a new package, like zope.password. They are really useful in any authentication system, even not related to zope3 the app server or zodb at all. That move will ease the reuse of password encoding/checking mechanism in other authentication software, so people won't need to install anything but password manager and zope.interface. The zope.schema is also needed for the password manager vocabulary, but I'm not sure if the vocabulary should go to the new package, because it adds a dependency on zope.schema. What do people think? - Move the functionality of zope.app.principalannotation to new package, zope.principalannotation, leaving only appsetup bootstrap subscriber and browser menu item, as well as compatibility imports in the original package. I'd volunteer to do that little refactorings, if noone objects. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope3docs - zopeframework
Hey, Jens Vagelpohl wrote: On Mar 5, 2009, at 17:55 , Martijn Faassen wrote: Jens, could you pick up zopeframework/trunk now for http://docs.zope.org/zopeframework? And put a redirect in place for http://docs.zope.org/zope3docs to the new location? We can then retire zope3docs. All done. Great, thanks Jens! I've just completed adding some bits and pieces to this documentation from the document I previously posted. How often does this get regenerated? Anyway, I expect the SVN changes will show up by tomorrow. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope3docs - zopeframework
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 5, 2009, at 17:55 , Martijn Faassen wrote: Jens, could you pick up zopeframework/trunk now for http://docs.zope.org/zopeframework? And put a redirect in place for http://docs.zope.org/zope3docs to the new location? We can then retire zope3docs. All done. I've just retired zope3docs and left a README.txt in place to avoid confusion. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Proposals: more refactoring
2009/3/5 Dan Korostelev nad...@gmail.com: The zope.schema is also needed for the password manager vocabulary, but I'm not sure if the vocabulary should go to the new package, because it adds a dependency on zope.schema. What do people think? Ah, I forgot that the password managers are intended to be registered and used as named utilities, so I guess zope.component and zope.schema dependencies are okay. Though, we could move that deps in the extra. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote at 2009-3-3 22:11 +0100: ... backwards compatibility at all costs, I agree that have erred on the side of too much backwards compatibility. That increased the overhead of changes tremendously and blocked innovation. Large applications are built upon the framework. If the framework too often drifts away, the maintenance costs for these applications gets too high -- and make the framework unattractive. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Proposals: more refactoring
Hey Dan, Thanks for taking the initiative to propose more refactorings! Dan Korostelev wrote: I'd like to continue moving code to saner places, so here's two more little ideas on next refactorings: - Move password managers from zope.app.authentication to a new package, like zope.password. They are really useful in any authentication system, even not related to zope3 the app server or zodb at all. That move will ease the reuse of password encoding/checking mechanism in other authentication software, so people won't need to install anything but password manager and zope.interface. +1 on moving these managers to zope.password. I know Uli did some work recently on a more secure way to store passwords. We should be sure in the documentation of zope.password to point out what the current best way to manage passwords is. The zope.schema is also needed for the password manager vocabulary, but I'm not sure if the vocabulary should go to the new package, because it adds a dependency on zope.schema. What do people think? I'd say leave the vocabulary behind in zope.app.authentication. It's a zope.app.* package so we'll surely get back to it to mine it for reusable stuff more. Perhaps the vocabulary is there to support the ZMI, or perhaps it'll have to go somewhere else. - Move the functionality of zope.app.principalannotation to new package, zope.principalannotation, leaving only appsetup bootstrap subscriber and browser menu item, as well as compatibility imports in the original package. +1 to this one too. I'd volunteer to do that little refactorings, if noone objects. Great! I think nobody will object, so feel free to go ahead. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Proposals: more refactoring
Dan Korostelev wrote: 2009/3/5 Dan Korostelev nad...@gmail.com: The zope.schema is also needed for the password manager vocabulary, but I'm not sure if the vocabulary should go to the new package, because it adds a dependency on zope.schema. What do people think? Ah, I forgot that the password managers are intended to be registered and used as named utilities, so I guess zope.component and zope.schema dependencies are okay. Though, we could move that deps in the extra. We still don't have to add the zope.schema dependency though, right? I'd say keep the vocabulary over in zope.app.authentication so we can avoid the zope.schema dependency. I don't want to create more extra dependencies. Extra dependencies should be going away as they make the graph harder to reason about, we don't want to add them. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope3docs - zopeframework
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 5, 2009, at 19:08 , Martijn Faassen wrote: Hey, Jens Vagelpohl wrote: On Mar 5, 2009, at 17:55 , Martijn Faassen wrote: Jens, could you pick up zopeframework/trunk now for http://docs.zope.org/zopeframework? And put a redirect in place for http://docs.zope.org/zope3docs to the new location? We can then retire zope3docs. All done. Great, thanks Jens! I've just completed adding some bits and pieces to this documentation from the document I previously posted. How often does this get regenerated? Anyway, I expect the SVN changes will show up by tomorrow. :) I just did a manual regeneration. The automatic build happens once a day around 7AM Eastern time. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmwHDEACgkQRAx5nvEhZLK4cgCfXwOIJk2u1tIeXinSAX3SDoMO mEQAmwWpbbUcMPUffU+RmRuC+6SrAeMo =UA/e -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] setup.py extra dependencies
Hi there, I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. I think they make the graph harder to reason about. That's bad, we want to reason about the system more easily. So I propose that: * we shouldn't create any new extra dependencies from now on. * we should investigate ways to remove the need for 'extra' dependencies. The latter point would of course not be done instantly, but if we agree we don't want to create *more* extra dependencies we can agree on starting with that policy right away. One place where extra dependencies are used quite a lot is in testing. One extra dependency that shows up a lot is a dependency on zope.app.testing. I think that *also* makes things much harder to reason about; testing dependencies should follow normal package dependencies. I therefore think zope.app.testing is one package we should be looking to get rid of eventually by splitting it up among a lot of 'testing' modules in individual packages. This way we won't have zope.app.testing sitting at an edge against our whole dependency tree. Since this is a lot of work this will be an ongoing project but we could at least agree we *want* to do this. Opinions? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
Martijn Faassen wrote: I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. I think they make the graph harder to reason about. That's bad, we want to reason about the system more easily. So I propose that: * we shouldn't create any new extra dependencies from now on. * we should investigate ways to remove the need for 'extra' dependencies. The latter point would of course not be done instantly, but if we agree we don't want to create *more* extra dependencies we can agree on starting with that policy right away. One place where extra dependencies are used quite a lot is in testing. One extra dependency that shows up a lot is a dependency on zope.app.testing. I think that *also* makes things much harder to reason about; testing dependencies should follow normal package dependencies. I therefore think zope.app.testing is one package we should be looking to get rid of eventually by splitting it up among a lot of 'testing' modules in individual packages. This way we won't have zope.app.testing sitting at an edge against our whole dependency tree. Since this is a lot of work this will be an ongoing project but we could at least agree we *want* to do this. Opinions? +1 Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
2009/3/5 Martijn Faassen faas...@startifact.com: Hi there, I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. I think they make the graph harder to reason about. That's bad, we want to reason about the system more easily. So I propose that: * we shouldn't create any new extra dependencies from now on. * we should investigate ways to remove the need for 'extra' dependencies. The latter point would of course not be done instantly, but if we agree we don't want to create *more* extra dependencies we can agree on starting with that policy right away. One place where extra dependencies are used quite a lot is in testing. One extra dependency that shows up a lot is a dependency on zope.app.testing. I think that *also* makes things much harder to reason about; testing dependencies should follow normal package dependencies. I therefore think zope.app.testing is one package we should be looking to get rid of eventually by splitting it up among a lot of 'testing' modules in individual packages. This way we won't have zope.app.testing sitting at an edge against our whole dependency tree. Since this is a lot of work this will be an ongoing project but we could at least agree we *want* to do this. Opinions? + for removing test extras. -0.75 for removing functionality extras. I still don't get how extras are different from additional packages. I'd also like to officially clear things about dependencies for zcml configuration. Most of our packages can be used nicely without any zcml, but the zcml-related dependencies can be quite large. I think that the extras here will do a nice job. I mailed about that a while ago. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
On Thu, Mar 5, 2009 at 1:43 PM, Martijn Faassen faas...@startifact.com wrote: * we shouldn't create any new extra dependencies from now on. +1 * we should investigate ways to remove the need for 'extra' dependencies. +1 I therefore think zope.app.testing is one package we should be looking to get rid of eventually by splitting it up among a lot of 'testing' modules in individual packages. This way we won't have zope.app.testing sitting at an edge against our whole dependency tree. +1 -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] deprecating the deprecation system?
Martijn Faassen wrote at 2009-3-5 17:35 +0100: Perhaps it's time to deprecate the deprecation system. ... Thoughts? +1 -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
On Thu, Mar 5, 2009 at 1:43 PM, Martijn Faassen faas...@startifact.com wrote: [snip proposal to stop using extras] Opinions? +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] deprecating the deprecation system?
On Thu, Mar 5, 2009 at 17:35, Martijn Faassen faas...@startifact.com wrote: * I've had good experience in the Grok project with just noting changes that might break code in the upgrade notes for Grok and telling people how to fix it. Using documentation more background can be provided and it can become a lot more clear what to do. True, but Grok-users will, thanks to it's new pre-1.0 status be more prepared for changes. Just an observation... I don't really have an opinion on the actual question. But I will talk out loud here: I think the goal, allowing third-party modules to support at least two versions of the framework at once, where commendable, but it may very well be that the work this caused was more than what it would be have been to support several versions by conditional imports etc in the third-party modules. On the other hand, if you have say, Zope 3.4 depends on zope.foobar 3.4.x, and you in zope.foobar 3.5.0 make a BBB-breaking refactoring without deprecation, and you then in 3.5.1 introduce a new, unrelated feature, it means you can't use that new feature in Grok while Grok still depends on Zope 3.4, which is a shame. But maybe not a problem. Deprecating would allow you to do that. It's probably an impossible task to have both backwards compatibility and still have innovation without loads of old cruft in the code. It becomes a balancing act. I don't know where to put that balance. Maybe we could have deprecation but for much shorter time. Say, between releases of the framework? Or we could simply not deprecate, but encourage backwards compatibilities, at least until a new major version is released of the framework? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
Previously Martijn Faassen wrote: I therefore think zope.app.testing is one package we should be looking to get rid of eventually by splitting it up among a lot of 'testing' modules in individual packages. This way we won't have zope.app.testing sitting at an edge against our whole dependency tree. Since this is a lot of work this will be an ongoing project but we could at least agree we *want* to do this. Opinions? I would like to see a move away from zope testing frameworks to a more standard testing infrastructure: setup.py test, possibly combined with using nose. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
On Thu, Mar 5, 2009 at 5:20 PM, Wichert Akkerman wich...@wiggy.net wrote: I would like to see a move away from zope testing frameworks to a more standard testing infrastructure: setup.py test, possibly combined with using nose. Wichert. Be aware of nose issue #102: http://code.google.com/p/python-nose/issues/detail?id=102 -- Sidnei da Silva ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
Previously Sidnei da Silva wrote: On Thu, Mar 5, 2009 at 5:20 PM, Wichert Akkerman wich...@wiggy.net wrote: I would like to see a move away from zope testing frameworks to a more standard testing infrastructure: setup.py test, possibly combined with using nose. Wichert. Be aware of nose issue #102: http://code.google.com/p/python-nose/issues/detail?id=102 Is there a particular reason to keep using the test_suite convention? Personally I much prefer nose's habit of automatically picking up tests. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote: Hi there, I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. ... Opinions? I disagree with the blanket statement. I do lean towards not having the extras for the test package only. I'm fine with the policy If you want zope.testing for your tests, then keep it as a dependency for the package. But I like to have the option of extras for testing additional setups. zc.async uses extras so that the main tests show the functionality as a Python library; another level adds more Zope dependencies, with associated tests; and the last level adds the most. I could have divided these up into multiple teensy-weensy packages but I didn't really want to. It seemed like overkill. I've also done this in other circumstances in which code could use zope.proxy/zope.security, but I really didn't want to add the hard dependency. The tests to show that proxies were handled correctly were only part of the extras. Dividing this package also would have made no sense--it was already just a few small classes. For a package as central as zope.component, I think the pattern Tres is pursuing--dividing everything up--makes sense. For most other packages, I personally feel that there are circumstances in which extras are a useful tool. I do wonder if there's a ``setup.py test`` spelling for testing these extras though. If there were not, I'd find that a good argument against the extras pattern, at least for core Zope packages. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
Hi there, Wichert Akkerman wrote: [snip] I would like to see a move away from zope testing frameworks to a more standard testing infrastructure: setup.py test, possibly combined with using nose. This is another discussion that has little to do with testing dependencies such as zope.app.testing. I'd therefore like to keep it out of this thread. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] deprecating the deprecation system?
Martijn Faassen wrote: Perhaps it's time to deprecate the deprecation system. From my personal view, I think the deprecation system works in certain cases in its current form. It does not work as the only means of documenting API changes for the evolution of software. I tend to think of software life cycles in the same way as most other processes work over time. Based on some status quo you get a rather predictable and slow-paced change rate for some time. We capture these in maintenance releases or minor feature releases. At a certain point the amount of innovation that has happened or the amount of dissatisfaction with the status quo gets too much and people urge for major change and revolution. We call those new major versions. The move from a 1.0 to 2.0 release, introducing major backwards incompatible changes. For Plone, we have adjusted our release strategy to match this model. Over two years there's a stable and predictable release series currently named 3.x. But people want major change and leave some of the baggage of the past. We call this the next major version numbered 4.0. The version numbers in the Zope community don't follow those normal practices of a 1.0, 2.0 and so forth scheme for known historical reasons. It's nevertheless the same cycle that happens. From a Zope2 perspective we have seen Five integration, major innovation and rapid change in Zope 2.7 and 2.8. It cooled down again and Zope 2.9 to 2.11 have only seen minor and predictable changes. Zope 2.12 tries to make major changes again. For Zope3 after the X3 release we had a period of still rapid changes for some time, but 3.2 up to 3.4 have been quite conservative. Now people want to change more things again at a more rapid speed without caring about byte-sized deprecation. I'd say that the deprecation system in its current form is well suited and has worked for the more silent times. It is not suited for covering the changes of a major new version. One of the problems with those major new versions is that often not only code constructs, import locations or the like change. We develop new approaches or best practices which need documentation in terms of real text explaining them including examples to show them. For Plone 4 we decided to not use the deprecation system on the level of import locations, but rather focus on writing articles and text documenting the changes. Once such a new major version is out, the deprecation system will be usable again and can cover the more slow paced evolution that will follow. It's a good tool, but not appropriate for the task at hand. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
Dan Korostelev wrote at 2009-3-5 22:14 +0300: ... -0.75 for removing functionality extras. I still don't get how extras are different from additional packages. I agree with Dan -- and add -1. The extras are equivalent to almost identical additional packages. If this makes reasoning more difficult, expand the graph in the trivial way before you start the reasoning. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
Gary Poster wrote: On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote: Hi there, I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. ... Opinions? I disagree with the blanket statement. I do lean towards not having the extras for the test package only. I'm fine with the policy If you want zope.testing for your tests, then keep it as a dependency for the package. But I like to have the option of extras for testing additional setups. zc.async uses extras so that the main tests show the functionality as a Python library; another level adds more Zope dependencies, with associated tests; and the last level adds the most. I could have divided these up into multiple teensy-weensy packages but I didn't really want to. It seemed like overkill. I've also done this in other circumstances in which code could use zope.proxy/zope.security, but I really didn't want to add the hard dependency. The tests to show that proxies were handled correctly were only part of the extras. Dividing this package also would have made no sense--it was already just a few small classes. For a package as central as zope.component, I think the pattern Tres is pursuing--dividing everything up--makes sense. For most other packages, I personally feel that there are circumstances in which extras are a useful tool. I do wonder if there's a ``setup.py test`` spelling for testing these extras though. If there were not, I'd find that a good argument against the extras pattern, at least for core Zope packages. It seems there is a 'tests_require' If your project's tests need one or more additional packages besides those needed to install it, you can use this option to specify them. It should be a string or list of strings specifying what other distributions need to be present for the package's tests to run. When you run the test command, setuptools will attempt to obtain these (even going so far as to download them using EasyInstall). Note that these required projects will not be installed on the system where the tests are run, but only downloaded to the project's setup directory if they're not already installed locally. http://peak.telecommunity.com/DevCenter/setuptools I've seen this used at least here: http://svn.supervisord.org/supervisor/trunk/setup.py Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Question: additional context for IAnnotations adapter?
Hi there! While looking at the zope.app.principalannotation package, I discovered that both zope.annotation and zope.app.principalannotation register their IAnnotations adapters twice: fisrt, as a simple adapter and second, as a multi adapter for some additional context object. The zope.annotation doesn't use that additional context at all - it just allows to get annnotations by multi-adapter lookup. The zope.app.principalannotation uses the additional context object as context argument for getSiteManager, which I believe is not needed and/or used in most cases, because application components, like zope.site provide their hooks to get the right site manager. There's no documentation or any tests for that behaviour neither in zope.app.principalannotation, nor in zope.annotation, so I made an assumption that these registrations are there just to support some very old annotation pattern, that was deprecated ages ago. If it's like that, I'd like to remove that registration for zope.principalannotation that is about to born as well as for zope.annotation. Can someone clarify this point? -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
2009/3/5 Gary Poster gary.pos...@gmail.com: On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote: Hi there, I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. ... Opinions? I disagree with the blanket statement. I do lean towards not having the extras for the test package only. I'm fine with the policy If you want zope.testing for your tests, then keep it as a dependency for the package. But I like to have the option of extras for testing additional setups. zc.async uses extras so that the main tests show the functionality as a Python library; another level adds more Zope dependencies, with associated tests; and the last level adds the most. I could have divided these up into multiple teensy-weensy packages but I didn't really want to. It seemed like overkill. I've also done this in other circumstances in which code could use zope.proxy/zope.security, but I really didn't want to add the hard dependency. The tests to show that proxies were handled correctly were only part of the extras. Dividing this package also would have made no sense--it was already just a few small classes. For a package as central as zope.component, I think the pattern Tres is pursuing--dividing everything up--makes sense. For most other packages, I personally feel that there are circumstances in which extras are a useful tool. A strong +1 on that explanation. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] setup.py extra dependencies
On Mar 5, 2009, at 5:02 PM, Laurence Rowe wrote: Gary Poster wrote: I disagree with the blanket statement. I do lean towards not having the extras for the test package only. I'm fine with the policy If you want zope.testing for your tests, then keep it as a dependency for the package. But I like to have the option of extras for testing additional setups. zc.async uses extras so that the main tests show the functionality as a Python library; another level adds more Zope dependencies, with associated tests; and the last level adds the most. I could have divided these up into multiple teensy-weensy packages but I didn't really want to. It seemed like overkill. ... It seems there is a 'tests_require' If your project's tests need one or more additional packages besides those needed to install it, you can use this option to specify them. It should be a string or list of strings specifying what other distributions need to be present for the package's tests to run. When you run the test command, setuptools will attempt to obtain these (even going so far as to download them using EasyInstall). Note that these required projects will not be installed on the system where the tests are run, but only downloaded to the project's setup directory if they're not already installed locally. Thanks for trying to help, but tests_require will not help here. When Gary wrote zc.async, he went to a great length to document it and make it useful for a wide variety of use cases. http://packages.python.org/zc.async/1.5.0/ There are three different zc.async configurations. 1. minimal 2. more 3. everything Each of the use cases above requires the packages for _both_ runtime and tests. The only way to provide all three options to developers is using extras. Which zc.async configuration you will actually use in your application depends on your needs and your application setup. For example, if you list zc.async [z3] you'll get the option 3 above. See the docs for zc.async for details, please. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] deprecating the deprecation system?
Hi Martijn Betreff: [Zope-dev] deprecating the deprecation system? Hi there, Perhaps it's time to deprecate the deprecation system. Why? * I've had good experience in the Grok project with just noting changes that might break code in the upgrade notes for Grok and telling people how to fix it. Using documentation more background can be provided and it can become a lot more clear what to do. It is always good to have such a documentation. But what does this have to do with removing a deprecation system? * using the deprecation system requires quite a bit of effort, as we're adding code. Do we test deprecations? That's quite a bit of energy spent there that we could instead spend on documentation. Yes, a deprecation system requires a lot of effort but that doesn't mean that the deprecation system is bad or good. I personaly think it's harder for me to write a good english documentation in the same time. But that's probably because I never learned english. * it's a zope-specific system no other Python projects use. Now we'll need some of them, but do we need this one? We have many things in zope which others don't use. That's no mesuring base for good or bad * we've not been very good at removing old deprecations over time. we can do it better * the deprecation system's messages have traditionally not been of a high quality. I recall occasions where it told me half of what to do, and certainly won't give me any background on what is going on. a unclear message is even better then no message * for moving code around we have an alternative system: a backwards compatibility import, documentation about what to do, and a tool part of the test runner which can point out indirect imports. I therefore propose we do the following: * look at any package which uses deprecation warnings now. * rip out the deprecation warnings and backwards compatibility code. Even if it's really expiring in 2010 (I doubt we have much of this). When you do so and you think anyone might still using that code path, please make a remark in zope3docs/source/migration/34to35.rst about what's going on and what people are to do. * run the compattests to see whether anything breaks. I think it's quite possible some deprecated code is in use by the Zope libraries themselves. :) I'm a little bit skeptic about this proposal. And I think no reason you listed does really explain why the deprecation system is bad. The only reason to use a deprecation system is to ensure that there is a deprecation period. I think the (real) reason why we can't use a deprecation system is that we don't like to support a deprecation period anymore because we like to evolve our package in a incompatible way now and not later. This makes our deprecation system useless and a migration path document is the only solution to handle that. Any other reason not using a deprecation system is just based on to less available time to support it or lazyness. btw, Right now it's very unclear how we identify versions like 3.4 / 3.5 What does that mean since packages have it's own versions e.g. 3.7.5 and are release within 3.4. How do you identify the zope version (3.4/3.5) of such a package? Thoughts? +/- 0 I let me surprise, let's try something new. We can still fallback to a deprecation system if everything else fails. Regards Roger Ineichen Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 ) ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Question: additional context for IAnnotations adapter?
Hi Dan Dan Korostelev wrote: Hi there! While looking at the zope.app.principalannotation package, I discovered that both zope.annotation and zope.app.principalannotation register their IAnnotations adapters twice: fisrt, as a simple adapter and second, as a multi adapter for some additional context object. The zope.annotation doesn't use that additional context at all - it just allows to get annnotations by multi-adapter lookup. The zope.app.principalannotation uses the additional context object as context argument for getSiteManager, which I believe is not needed and/or used in most cases, because application components, like zope.site provide their hooks to get the right site manager. There's no documentation or any tests for that behaviour neither in zope.app.principalannotation, nor in zope.annotation, so I made an assumption that these registrations are there just to support some very old annotation pattern, that was deprecated ages ago. If it's like that, I'd like to remove that registration for zope.principalannotation that is about to born as well as for zope.annotation. Can someone clarify this point? I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time). In both cases it is important that the annotations are looked up in some context rather than in whatever the current site happens to be. Hope this helps Jacob ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope.publisher
Hi Martijn Betreff: Re: [Zope-dev] zope.publisher Roger Ineichen wrote: Does grok need to register this new adapter somewhere? If the adapter configuration is missing the default skin apply pattern will break. As long as zope.publisher's configure.zcml does it, Grok will load that up. Grok isn't different in that respect; it only uses Grok-style registration in packages that explicitly use grok or grokcore.* libraries. It's quite possible Grok can start using some of your changes for its REST skin implementation (which do apply to IBrowserRequest), though I'm not 100% sure. of corse, all changes are 100% compatible. The changes allow you to inherit from IHTTPRequest instead of IBrowserRequest and support a IDefaultSkin. The previous implementation required that the default skin pattern uses an IBrowserRequest. REST does normaly depend on IBrowserRequest but JSON-RPC doesn't have to, or you will get all the IBrwoserRequest parts in JSON-RPC too which is not good. Also XML-RPC has to be inherited from IHTTPRequest and not how it is right now from IBrowserRequest. XML-RPC should also allow to use it's own default skin and not depend on the IBrowserRequest default skin implementation. e.g. we do really not need a contents.html page in XML-RPC skins. But that's another (security) topic which we can discuss at a later time. I'm trying to understand why the default default skin cannot be registered as an interface, instead of the introduction of an adapter. Is this because defaultSkin can only be used for IBrowserRequest? Because it's not an adapter. It's doens't provide what it should provide and is registered for. The following will end in a TypeError: request BrowserRequest() defautlSkin = IDefaultskin(request) TypeError ... but it should return: IDefaultBrowserLayer Another side effect is that we get pickled interfaces in the adapter registry. That really hurts if someone does the same in a local (persistent) adapter registry and the interface get removed. The question is, should we allow to register such *junk* in the zope adapter registry? I think you need to update the upgrade notes in zope3docs too to point out this change. If there is anything people should change to their code, you need to explain how to find what needs to be changed and what change to make. You need to at least warn them that something big changed if they get problems with their skins and point them to zope.publisher's changelog. will do so soon I'll also note that this is *not* a minor bugfix release of zope.publisher, so it should be 3.6 not 3.5.7. Also don't use 'dev' markers in CHANGES.txt; only in setup.py. agreed Regards Roger Ineichen Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 ) ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: Martijn Faassen wrote at 2009-3-3 22:11 +0100: ... backwards compatibility at all costs, I agree that have erred on the side of too much backwards compatibility. That increased the overhead of changes tremendously and blocked innovation. Large applications are built upon the framework. If the framework too often drifts away, the maintenance costs for these applications gets too high -- and make the framework unattractive. But if the framework is no longer monolithic, you can keep using the bits you need for BBB, while selectively updating newer pieces. The more loosely-coupled the pieces are, the more likely such a partial upgrade is to work. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com 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 iD8DBQFJsIWO+gerLs4ltQ4RAlWuAKCwUyNkbz9zKaLHgWp/WwTTPjufVgCePgxk PIIdR4FnOAUMuJgKupdjpYQ= =WiRX -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Stripping down zope.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Thanks for the clarifications concerning registries. Does the multiple registry situation mean any changes to the implementation of the ZCML directives at all or will they just work as soon the underlying registry situation is adjusted? All the directive handlers do is create actions and add them to the parsing context: http://svn.repoze.org/repoze.zcml/trunk/repoze/zcml/__init__.py There isn't any there there, in the sense you are looking for. Another point is that we need to make sure we have a path for libraries that use zope.component[zcml] to upgrade. Actually, we don't need an upgrade path. We can just leave a 'meta.zcml' in zope.component which includes the new locations. That file will be *inert*, and doesn't therefore need testing, because none of the directive implementations will be present. Over time, people can shift to including the new meta.zcml at their leisure. We can leave the redirecting meta.zcml in zope.component *forever*, if need be. The subscribers registered in zope.component's configure.zcml are a different story: I have a YAGNI feeling in my gut about them, but haven't dug into who actually subscribes to verify it. At any rate, we can leave that zcml file as is unless / until we decide to rip out the zope.event dependency. They will now need to import zope.componentzcml at the least, but where does that leave zope.persistentregistry? Who needs to depend on this? zope.site or something like that? zope.site doesn't need *persistent* registries. The traversal bit of the publisher just needs to notice that the traversed object implements the I'm a site interface, and call 'setSite'. The only code which *needs* persistent registries is the code which *implements* a registry as an attribute of a persistent object implementing that marker interface. Anyway, this upgrade path needs to be spelled out clearly in the zope.component CHANGES.txt pointing people in the right direction. We also need to spell it out in this document: http://svn.zope.org/zope3docs/source/migration/34to35.rst Maintaining that document is out of scope for me. ;) (I hope this and related documents will soon move to the 'zopeframework' area) It'd be nice if we could organize some volunteers to check and adjust any dependencies on zope.component that would need to be adjusted. I think that mainly means checking those places that actually rely on zope.component[zcml], but I think the baseregistry refactoring means checking some other places as well. I think that the *real* clients of that extra are all the site.zcml files which which do the following: include package=zope.component name=meta.zcml/ The tiny fraction of hardcore types who actually import the zope.component.zcml module are certainly competent to adjust those imports. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com 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 iD8DBQFJsIk5+gerLs4ltQ4RArFaAJ4m+OBOzd1zMszKu/UnmIwSgmGtkgCfbtso mRJBgLU7muEomTu04VjfnKw= =J4da -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] non-zodb persistent registries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Hey Tres, Tres Seaver wrote: 2. Move the persistent registry stuff out into another package, including whatever support is needed to allow for people to migrate existing persistent references. Effectively, this moves one extra out to a package, *including* its testing dependencies. zope.persistentregistry (BIKESHED NAMING ALERT) depends on: - zope.configuration - ZODB3 I was interested to see this for the reason I gave in the subject line, and it might affect the naming of this package... Might I suggest zope.zodbregistry for this? The reason being that, for a long time, I've wanted to see a persistent registry that stored in a rdb rather than zodb. I don't know what that would look like. I note that the bfg application registry is actually picklable, because we don't use any non-inert actions. The expected gain in startup time turned out to be negligible, so we don't worry about trying to do this any more. However, I'm a bit stumped at how to implement this and certainly having the zodb-based registry mixed in with the zope.component code confused the hell out of me when I last looked. The one that particularly got me was how, in a multi-process/multi-thread setup such as a wsgi app, you would get other threads'/processes' registries to update themselves when a registry in one thread/process was changed. Any ideas how to do this? Nope. I've never given it any thought. We do actually have this problem with the text-file based registry, it's just that we accept a restart of the server is needed when that text file changes. A nice to have would be an equivalent of apache's reload command. I don't actually understand the usecase: changing configure.zcml is a development activity, not a sysadmin one. Is anyone else interested in this kind of stuff? Theoretically, yes. Practically, no: I'd rather keep my startup times under a second. ;) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com 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 iD8DBQFJsIo7+gerLs4ltQ4RAg+TAKDCdIvtEqka6uvc8wKiXDZlBsQ35wCcCh/J 4tlunsHE7rKC9Wu5vEjAGio= =i8kO -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] deprecating the deprecation system?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hi there, Perhaps it's time to deprecate the deprecation system. Why? * I've had good experience in the Grok project with just noting changes that might break code in the upgrade notes for Grok and telling people how to fix it. Using documentation more background can be provided and it can become a lot more clear what to do. * using the deprecation system requires quite a bit of effort, as we're adding code. Do we test deprecations? That's quite a bit of energy spent there that we could instead spend on documentation. * it's a zope-specific system no other Python projects use. Now we'll need some of them, but do we need this one? * we've not been very good at removing old deprecations over time. * the deprecation system's messages have traditionally not been of a high quality. I recall occasions where it told me half of what to do, and certainly won't give me any background on what is going on. * for moving code around we have an alternative system: a backwards compatibility import, documentation about what to do, and a tool part of the test runner which can point out indirect imports. I therefore propose we do the following: * look at any package which uses deprecation warnings now. * rip out the deprecation warnings and backwards compatibility code. Even if it's really expiring in 2010 (I doubt we have much of this). When you do so and you think anyone might still using that code path, please make a remark in zope3docs/source/migration/34to35.rst about what's going on and what people are to do. * run the compattests to see whether anything breaks. I think it's quite possible some deprecated code is in use by the Zope libraries themselves. :) Thoughts? I'm already on record as favoring this strategy. ;) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com 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 iD8DBQFJsIuF+gerLs4ltQ4RAinsAKCOPGiU+IOTHNlbry4fyRK7/eF+UQCcDXPp EiBufuv8s02yz4wk2oLljpw= =9juK -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] zope.publisher dependencies
Jim Fulton wrote: - It's not well enough documented. While I think there's merit in doing some things at the WSGI level, I remain pretty happy with the publication interface for separatating generic publisher functions from application policies. I which the use of this API was better communicated and understood. I hope you're not asking me to write documentation for zope.publisher :-), because I only understand the mechanics. The overall scope and purpose is cloudy to me. In particular, I don't understand how the publication interface is actually generic. Does it fit the needs of anything other than Zope? A less major complaint is some baggage from the past. There are a number of request features that I never use and tend to forget about. The biggest of these is the special form data unmarshalling and url manipulation support. (I was amused to read in your introduction to your pipeline proposal that people wanted to know the answer to the question: When does Zope respect the :method form variable?. :) FWIW, that particular functionality has been pulled out twice now, both in repoze.monty and zope.httpform. As a baby step, we could make zope.publisher depend on zope.httpform. (I made zope.httpform without knowing repoze.monty already existed, but zope.httpform has more tests and interfaces and it's hosted on svn.zope.org, so I think zope.httpform is worth keeping.) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
