[Zope-CMF] Re: future of getToolByName
whit wrote: > I remember some discussion of this in the past. > > Transitionally, it would be helpful to be able to register local > utilities to a tool name, and then have getToolByName spit out a > deprecation warning and return an appropriate object. > > thoughts? comments? does this exist somewhere already? Hmm... I'm not sure this is useful unless we map standard utilities to the equivalently functioning tool (which I don't think is a good idea). So if thats not the case, and developers need to learn all the new names, I'd suggest they use the standard zope3 way of looking up utilities. Just my opinion of course. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
i'm -1 for expending extra effort to get this working on Zope 2.8. new features should arrive w/ new versions. Plone 2.5 will require CMF-1.6, which will work w/ both Z2.8 and Z2.9. those who want this feature can run Plone on Z2.9, no prob. i'd much rather see us focus our efforts on getting people migrated forward to Z2.9 than give them reason to stay on Z2.8 yet longer. it's bad enough that we have to support Z2.8 w/ Plone 2.5, let's not make it worse. -r ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Move GenericSetup out of CMF
On 16 Jan 2006, at 18:28, Jens Vagelpohl wrote: On 15 Jan 2006, at 18:38, Jens Vagelpohl wrote: Before cutting the CMF 2.0 alpha GenericSetup should move out of the CMF repository. I'm volunteering to do that. Is there anything or anyone I need to wait on before doing so? Everyone: I'll be working on this tonight. Please get all checkins into GenericSetup done by 7:30 PM CST. Work finished, please check out GenericSetup from here now: svn+ssh://svn.zope.org/repos/main/GenericSetup/trunk Tests are passing (except for the known five_actionstool breakage) as before. If you notice anything that I missed please let me know. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] future of getToolByName
I remember some discussion of this in the past. Transitionally, it would be helpful to be able to register local utilities to a tool name, and then have getToolByName spit out a deprecation warning and return an appropriate object. thoughts? comments? does this exist somewhere already? -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Move GenericSetup out of CMF
On 15 Jan 2006, at 18:38, Jens Vagelpohl wrote: Before cutting the CMF 2.0 alpha GenericSetup should move out of the CMF repository. I'm volunteering to do that. Is there anything or anyone I need to wait on before doing so? Everyone: I'll be working on this tonight. Please get all checkins into GenericSetup done by 7:30 PM CST. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup zcml registration of profiles
Rocky Burt wrote: Tres Seaver wrote: Florent Guillaume wrote: I propose to add a new directive "registerProfile" in GenericSetup so that profile registration can be done through zcml. What namespace should I use? How about 'http://namespaces.zope.org/genericsetup'? Ohh, could I state the obvious and suggest the default namespace prefix for genericsetup should be "setup" ? :) I think "setup" is a bit too generic. And "genericsetup" is therefore less generic :):) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup list property purge
Florent Guillaume wrote: I recently introduced the fact that in extension profiles list properties aren't purged by default. But really this introduces problems, as if you simply import an extension profile twice you'll get all you lists doubled. So I think I'll use the opposite semantic, closer to what was the case before: purge by default for lists even in extension profiles, except if purge="False" is present on the property. I checked this in. But actually this revealed what I think is slightly unclear behaviour in the case of loading extension profiles: the extension profile can happily modify objects without them being purged, but I believe that as soon as it has to create a new object, the import context should be switched to _should_purge=True for that object and the recursion inside it. What do you think? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Florent Guillaume wrote: > Rocky how does your effort relate to Basket by the way? ISTR that Basket > aims at answering a similar use case. Basket is for distributing zope2 products in egg form. I've been working with Chris closely on it. In fact I added the support that allows people to write zope2 products without the toplevel Products namespace package with eggs for Basket. Its there where I discovered the more prominent area's that needed to be monkey patched and reused that knowledge when adding similar work to Five. Once everything lands in Zope 2.10, there will be no need for the monkies in Basket (or possibly even Basket itself) or this Five work. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: The general use case is to stop having to put things in Products. When now writing Zope 2 software, a lot of code basically expects stuff to be in Products, Rocky's modifications make that go away and add a ZCML directive to let Zope 2 pick up packages from outside Products (so that they will still receive the same initialization features and an entry in the Control_Panel, etc.). Rocky how does your effort relate to Basket by the way? ISTR that Basket aims at answering a similar use case. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] GenericSetup list property purge
I recently introduced the fact that in extension profiles list properties aren't purged by default. But really this introduces problems, as if you simply import an extension profile twice you'll get all you lists doubled. So I think I'll use the opposite semantic, closer to what was the case before: purge by default for lists even in extension profiles, except if purge="False" is present on the property. Opinions? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup zcml registration of profiles
Tres Seaver wrote: > Florent Guillaume wrote: > >>>I propose to add a new directive "registerProfile" in GenericSetup so >>>that profile registration can be done through zcml. >>>What namespace should I use? > > > How about 'http://namespaces.zope.org/genericsetup'? Ohh, could I state the obvious and suggest the default namespace prefix for genericsetup should be "setup" ? :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup zcml registration of profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: > I propose to add a new directive "registerProfile" in GenericSetup so > that profile registration can be done through zcml. > What namespace should I use? How about 'http://namespaces.zope.org/genericsetup'? Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDy8TR+gerLs4ltQ4RAp+CAKCNoQetpZE0dOPdUEkPr0gQmt8qaQCeP7iE TPMr+NZsA8CyzFy07OlAT1A= =vcQD -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: Hi there, Just to comment on this interchange: Tim Hicks isn't the only one who we'd need to explain a few things to in the new world order. We may end up with people just dumping packages in SOFTWARE_HOME's 'lib/python' directory if we're not careful. I have some worries with the current Zope 3 world, as already expressed in some earlier discussions with Philipp. There are right now too many different ways people package their Zope 3 extensions. I feel your concern about having more than one way to do it. and about this causing some confusion. But drawing line in the sand for features that initially will only benefit developers seems like a bad idea to me. But I think the value in starting align development style in z2 with the rest of the python world outweighs a small spike in support burden. In actuality, the number of products that anyone depends on will not be using this in 2.8, but making it available to 2.8 will give people an opportunity to use this and familiarize themselves. for example, Plone will be on 2.8 for at least another 6 or more months. And some Plone installations, indefinitely longer... an education problem is an education problem now or later. On the issue of where packages go, we do need some conventions and giving zope it's own "golden path" would be a publicity boon as well as easier for everyone. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: > Then again, I'm not absolutely against continuing the Five 1.2 line with > new features. How to name it is indeed tricky. Perhaps in favor of > comprehensibility we just want to name it 1.2.1, even though we add new > features. +1 -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: > Yes. In fact, if one exists, it's automatically put on your PYTHONPATH > for that instance. I think we should make Zope 2.8+ instance skeleta > grow a lib/python directory. This can hardly be considered a feature, so > we should be able to sneak it into the next bugfix releases of 2.8 and 2.9. +1 I was discussing this with someone a while back asking why we shouldn't just add this directory to the standard instance structure. A lot of zope2 developers still don't realize that INSTANCE_HOME/lib/python can exist and will get used if it does exist. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: > Fair enough. It seems to several people, though, that explaining to > people how Python packages are installed and then how you hook up these > packages into your instances is easier than explaining all the magic > that revolves around Products to them. Because in the end you won't have > to explain how to install Python packages at all because it's the same > all the time... Indeed, its time for Zope developers to think less like zope developers and think more like python developers :) >>How urgent is it that all of this works with Zope 2.8? I guess it's >>urgent if you want to sell it to the Plone community, which will only >>switch to Zope 2.9 or beyond by next year or so, I expect. How much more >>often is this kind of thing therefore going to happen? > > > Given Plone hasn't adopted time-based releases yet, I'm not sure. AFAIK > they want time-based releases, 6 months apart like Zope. Just yesterday > I suggested they make them 3 months off to the Zope releases. That way > they can keep on track with Zope releases and not lag behind all the time. My understanding is that Plone 2.1 -> 2.5 was meant to be the first time based release. But Alec Mitchel would have to answer that one, being the release manager. I do support sync'ing these plone 6 month release cycles with zope's releases (being 3 months off) and I think I heard a few plone people second the sentiment. >>You can turn that around; for consistency of installation experience in >>Zope 2.8, it's important that people don't get a new way of installing >>products, confusing innocent individuals installing Zope software. For >>the "cutting edge", Zope 2.9, that argument is slightly different. Well, any non-familiar zope2 sys admin who's installed plugins has almost certainly had to install python code in site-packages as well. Telling them "oh, you can just stick this on site-packages as well, or put it in INSTANCE_HOME/lib/python if you need different versions with different zope instances" I think won't confuse innocent individuals. >>I want to identify the reasons why it is so important that this change >>happens with Zope 2.8. The main reason I can identify is Plone, correct? Single biggest reason is so that people developing products within the next 6-12 months can develop using this new style. Of course we can say that as a consultant we just require our clients to upgrade to Zope 2.9, but the reality is we all have plenty of clients who won't be able or willing to make the upgrade from Zope 2.8 to 2.9 especially with the leap of going from py2.3 to py2.4. This has the biggest bearing on Plone because even though Plone 2.5 will support zope 2.8 and 2.9 both (I actually tried to convince them to drop support for 2.8, but that didn't work out), the majority will use zope 2.8 -- based on experience with Plone 2.1 supporting Zope 2.7 and 2.8 where most Plone 2.1 installs still seem to use Zope 2.7. I'm not a great debater by any means so I'll finish this with one more reason as to why and make Zope 2.8 support this functionality -- because it will make my life a great deal easier :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: > Okay, I read CMF 2.0 is targetting Zope 2.9 now, but Plone is, as of > yet, still targeting CMF 1.6. Whether they really will I guess also > depends on Plone's commitment to release this spring and suppress > changing things around. I think there are two reasons Plone 2.5 is targetting CMF 1.6 (instead of just going to CMF 2.0) 1) the risk that CMF 2.0 wouldn't be ready when plone -- and I'm pretty sure the 6 month release rule has already been adopted for Plone with Plone 2.1 -> 2.5 trying to be the first 6 month interval 2) CMF 2.0 changes too many things -- because of the plethora of existing plone products out there and the pains that people are going through porting them from Plone 2.0 -> 2.1, the Plone community is striving to not do the same thing going from Plone 2.1 -> 2.5 - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: > Just to comment on this interchange: Tim Hicks isn't the only one who > we'd need to explain a few things to in the new world order. We may end > up with people just dumping packages in SOFTWARE_HOME's 'lib/python' > directory if we're not careful. You're right, we haven't prepared people enough for this. I thank Tim for bringing this problem to my attention :). Being an advocate of lib/python (or at least the zope3ish way of doing extensions), I should take some responsibility here. First thing I'll do today is make sure Zope 2.8+ instances will have a lib/python dir with a proper README.txt. I will also write a blog entry. > I have some worries with the current Zope 3 world, as already expressed > in some earlier discussions with Philipp. There are right now too many > different ways people package their Zope 3 extensions. I know 2 different ways: INSTANCE_HOME/lib/python and site-packages. I think both are sensible and both should be easy enough to understand, even for brainwashed Zope2istas... Perhaps I'm missing other ways... Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Sidnei da Silva wrote: > On Mon, Jan 16, 2006 at 01:12:46PM +0100, Philipp von Weitershausen wrote: > | Sidnei da Silva wrote: > | > On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: > | > | Then again, Zope 2.9 is "stable" (people don't really trust a .0 > | > | release) and we could release Five 1.4 any time after Rocky is done. So > | > | there's really no reason for people NOT to upgrade, I guess. > | > > | > There is at least one reason: People running python2.3 must switch to > | > python2.4 for Zope 2.9. That's somewhat painful, at least on > | > Windows. > | > | AFAIK installing multiple Python versions on Windows isn't a problem. > | Plus, doesn't Zope 2 ship with its own Python anyways? > > Yes, the issue is not installing python, but packaging Zope. People > building installers for Windows have to have a MSVC > 7 and there > might be a significant amount of work involved on making all > dependencies of those installers work on Python2.4. True. Good point. But for how long do these people (I assume Enfold is one of them) plan to stick with Zope 2.8 then? I mean, they have to move forward at *some* point. Sure, it won't happen over night, but neither will Products-less packages in Zope 2... Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Tim Hicks wrote: >>>Coming at this with a zope 2 head on, it seems to me that it might be >>>nice if I could carry on using the Products directory so that when I add >>>new 'products', I don't have to mix them in with the core zope code in >>>lib/python/. >> >>What do you mean by "core zope code"? Zope lives in >>SOFTWARE_HOME/lib/python, e.g. /usr/local/Zope-2.9.0/lib/python, your >>own python packages live in INSTANCE_HOME/lib/python, e.g. >>/var/zope/foobar.com/lib/python. > > Ah, ok, I think I am/was confused between INSTANCE_HOME and > SOFTWARE_HOME. Part of the confusion stems from me looking at the > directories that I have in my Zope 2.8.1 instance and seeing the following: > > [EMAIL PROTECTED] ~/zope/instance1 : ls -l > total 16 > drwxr-xr-x 2 tim2p tim2p 512 Sep 20 01:28 Extensions > drwxr-xr-x 47 tim2p tim2p 1536 Jan 15 23:20 Products > -rw-r--r-- 1 tim2p tim2p 410 Sep 19 21:44 README.txt > drwxr-xr-x 2 tim2p tim2p 512 Sep 19 21:44 bin > drwxr-xr-x 2 tim2p tim2p 512 Sep 19 21:44 etc > drwxr-xr-x 2 tim2p tim2p 512 Jan 11 10:48 import > drwxr-xr-x 2 tim2p tim2p 512 Dec 19 02:49 log > drwxr-xr-x 3 tim2p tim2p 512 Jan 16 12:14 var > > No lib/ (and therefore, no lib/python/) directory. Once I saw you guys > talking about lib/python/, I assumed you must have meant the one in > SOFTWARE_HOME. > > Presumably instances are going to grow a lib/python/ directory too. Yes. In fact, if one exists, it's automatically put on your PYTHONPATH for that instance. I think we should make Zope 2.8+ instance skeleta grow a lib/python directory. This can hardly be considered a feature, so we should be able to sneak it into the next bugfix releases of 2.8 and 2.9. > How > would that be different to just having those packages that appear in the > current (INSTANCE_HOME) Products/ directory just be directly importable > without the "Products." part in the import statement? I suppose > lib/python/ is more normal in the python world... Yeah, lib/python is a bit more normal (though it adds that extra path element which feels like clutter). Plus, your suggestion with a two-faced Products (once a PYTHONPATH container, once a top-level package) would make everything a bit ambiguous. Also, Products sort of acts as a namespace package. When we move to top-level packages, people might want to choose different namespace packages (e.g. Plone would hopefully choose 'plone' instead of 'CMFPlone' and the CMF might regroup everything under 'cmf', e.g. 'cmf.core', 'cmf.default', etc.) Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
On Mon, Jan 16, 2006 at 01:12:46PM +0100, Philipp von Weitershausen wrote: | Sidnei da Silva wrote: | > On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: | > | Then again, Zope 2.9 is "stable" (people don't really trust a .0 | > | release) and we could release Five 1.4 any time after Rocky is done. So | > | there's really no reason for people NOT to upgrade, I guess. | > | > There is at least one reason: People running python2.3 must switch to | > python2.4 for Zope 2.9. That's somewhat painful, at least on | > Windows. | | AFAIK installing multiple Python versions on Windows isn't a problem. | Plus, doesn't Zope 2 ship with its own Python anyways? Yes, the issue is not installing python, but packaging Zope. People building installers for Windows have to have a MSVC > 7 and there might be a significant amount of work involved on making all dependencies of those installers work on Python2.4. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: >>> Is Plone 2.5 still targeting Zope 2.8? >> >> Yes. > > > Yes to which question? Yes to "Is Plone 2.5 still targeting Zope 2.8". >>> Perhaps these use cases aren't >>> driven by Plone/CMF core and some other packages would like to use >>> this in Zope 2.8? Can they be identified? >> >> >> The general use case is to stop having to put things in Products. When >> now writing Zope 2 software, a lot of code basically expects stuff to be >> in Products, Rocky's modifications make that go away and add a ZCML >> directive to let Zope 2 pick up packages from outside Products (so that >> they will still receive the same initialization features and an entry in >> the Control_Panel, etc.). > > I know what the modifications allow you to do. > > It's a fundamentally different way of developing and installing > products. Therefore it's good to ask why we would want to expose such a > fundamentally new feature for Zope 2.8. Do we really want to start > explaining to people that "My product is special, you need to install it > like this, unlike what you're used to" when what we're dealing with is > not even the most recent stable release of Zope? > > To be clear: I realize that this effort is to make things *less* special > for Zope on the long term, and I support it's overall it with some > reservations, but we have to think about the tactical short term too. Fair enough. It seems to several people, though, that explaining to people how Python packages are installed and then how you hook up these packages into your instances is easier than explaining all the magic that revolves around Products to them. Because in the end you won't have to explain how to install Python packages at all because it's the same all the time... As somebody who's somewhat involved in Zope documentation, I am one of those above mentioned people. > For how long do we intend to evolve new features for what is not the > most recent stable release of Zope? I.e. we can make the argument that > this should be in the hands of the people soon for just about any new > feature in Five. Good point. > How urgent is it that all of this works with Zope 2.8? I guess it's > urgent if you want to sell it to the Plone community, which will only > switch to Zope 2.9 or beyond by next year or so, I expect. How much more > often is this kind of thing therefore going to happen? Given Plone hasn't adopted time-based releases yet, I'm not sure. AFAIK they want time-based releases, 6 months apart like Zope. Just yesterday I suggested they make them 3 months off to the Zope releases. That way they can keep on track with Zope releases and not lag behind all the time. >> The reason for doing so is simple: Products is bound to go away. It >> gives a lot of people a lot of pain. With a lot of Zope 3 technology >> entering many Zope 2 projects, it would be good to get a clean slate >> early on: put new stuff on Product-less packages. > > > You can turn that around; for consistency of installation experience in > Zope 2.8, it's important that people don't get a new way of installing > products, confusing innocent individuals installing Zope software. For > the "cutting edge", Zope 2.9, that argument is slightly different. > > I want to identify the reasons why it is so important that this change > happens with Zope 2.8. The main reason I can identify is Plone, correct? I let Rocky take this one. I don't really feel strongly about having this available in Zope 2.8. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: browser views and memoization
yuppie wrote:
whit wrote:
yuppie wrote:
I ended up using this method as decorator for most methods:
def memoize(func):
memo = {}
def memoized_func(*args):
if args not in memo:
memo[args] = func(*args)
return memo[args]
return memoized_func
Are there better ways to resolve this?
Will those memo dicts be removed together with the view object or
does this create a potential memory leak? (I'm not very familiar with
decorators.)
that's pretty elegant compared to shoving a multitude of values into
the view. The closest thing to it would be a PEAK binding, but even
that can't handle the variety of situations that keing the memo by
function signature gives you. very nice.
Besides the fact it doesn't work :(
that looks safe; as far as I can tell when the decorated method is
garbage collected with the view, all refs to 'memo' should be reaped..
Digging a bit deeper it looks like decoraters are created on class
level, not on instance level. So 'memo' is not garbage collected with
the view, it's the same for all instances and grows with each request.
That's not exactly the behavior I want.
Have to think about it a bit more. Any input is welcome.
Ok. This *seems* to work:
def memoize(meth):
def memoized_meth(self, *args):
if not hasattr(self, '_memo'):
self._memo = {}
sig = (meth, args)
if sig not in self._memo:
self._memo[sig] = meth(self, *args)
return self._memo[sig]
return memoized_meth
_memo is now an instance attribute and should be garbage collected with
the view instance. Does that look sane?
I don't care about kwargs and non-hashable args at the moment. I just
want to find out if using a memoize decorator is the right approach for
resolving the problem described in my initial mail.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
On 1/16/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > It's a fundamentally different way of developing and installing > products. Therefore it's good to ask why we would want to expose such a > fundamentally new feature for Zope 2.8. Do we really want to start > explaining to people that "My product is special, you need to install it > like this, unlike what you're used to" when what we're dealing with is > not even the most recent stable release of Zope? You have a good point there. I think we can happily require Zope 2.9 for this functionality. If you are bleeding edge, you can be required to be so on all fronts. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Sidnei da Silva wrote: > On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: > | Then again, Zope 2.9 is "stable" (people don't really trust a .0 > | release) and we could release Five 1.4 any time after Rocky is done. So > | there's really no reason for people NOT to upgrade, I guess. > > There is at least one reason: People running python2.3 must switch to > python2.4 for Zope 2.9. That's somewhat painful, at least on > Windows. AFAIK installing multiple Python versions on Windows isn't a problem. Plus, doesn't Zope 2 ship with its own Python anyways? > I don't recall if OS X comes with Python 2.4 by default. Tiger ships with Python 2.3.5. However, compiling Python 2.4 from source is a piece of cake, let alone fink, darwinports or gentoo portage which provide the same kind of packaging capabilities to OSX as they do to Linux/Unix distributions. I haven't met a single developer who uses OSX and doesn't use at least one of those. And there's also MacPython which is a pointy-clicky installer for OSX; it's also available for Python 2.4, IIRC. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote: | Then again, Zope 2.9 is "stable" (people don't really trust a .0 | release) and we could release Five 1.4 any time after Rocky is done. So | there's really no reason for people NOT to upgrade, I guess. There is at least one reason: People running python2.3 must switch to python2.4 for Zope 2.9. That's somewhat painful, at least on Windows. I don't recall if OS X comes with Python 2.4 by default. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Tim Hicks wrote: >>>The reason for doing so is simple: Products is bound to go away. It >>>gives a lot of people a lot of pain. With a lot of Zope 3 technology >>>entering many Zope 2 projects, it would be good to get a clean slate >>>early on: put new stuff on Product-less packages. >> >>You can turn that around; for consistency of installation experience in >>Zope 2.8, it's important that people don't get a new way of installing >>products, confusing innocent individuals installing Zope software. For >>the "cutting edge", Zope 2.9, that argument is slightly different. > > > Coming at this with a zope 2 head on, it seems to me that it might be > nice if I could carry on using the Products directory so that when I add > new 'products', I don't have to mix them in with the core zope code in > lib/python/. What do you mean by "core zope code"? Zope lives in SOFTWARE_HOME/lib/python, e.g. /usr/local/Zope-2.9.0/lib/python, your own python packages live in INSTANCE_HOME/lib/python, e.g. /var/zope/foobar.com/lib/python. > But the separation of 'core' and 'extras' gives me a comfortable > feeling. Is it just me? Am I just stuck in the past? I think you're just confusing software home vs. instance home. We're not making you put stuff into software home (although you can if you really want to... you can even put stuff into site-packages or anywhere you want as long as it's in PYTHONPATH). Plus, just the fact that stuff *being* somewhere in the PYTHONPATH doesn't mean it gets loaded. You have to add a ZCML slug to INSTANCE_HOME/etc/package-includes first. So, you could install a package globally and just make it available to certain instances by placing a slug or not. This is how package deployment works in Zope 3 and it's where we're heading with Zope 2 as well. See http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_01_11_mata-los-productos for further info and some ranting as well as constructive suggestions. Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
On 16 Jan 2006, at 11:26, Philipp von Weitershausen wrote: Martijn Faassen wrote: Are we really sure a further Five feature release for Zope 2.8 is actually needed? What's happening with CMF and Plone in this regard? Is Plone 2.5 still targeting Zope 2.8? Yes. Is CMF? CMF 1.6 is. I hope CMF 2.0 is not. CMF 1.6 will retain Zope 2.8 compatibility. CMF 2.0 is targeted at Zope 2.9. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: >> In an earlier thread I argued that this modified version of Five 1.2 >> should perhaps get a new name to indicate the additional feature. Do you >> all think that this would be feasible, or should we just go on with >> 1.2.1? If we give it a new name, the question is obviously which. 1.3 is >> already taken so we need some sort of suffix (a letter perhaps). >> Suggestions are welcome :). > > > Ugh, soon we'll get Five 1.2-RC3-beta5-whatever. :) Hehe. > Are we really sure a further Five feature release for Zope 2.8 is > actually needed? What's happening with CMF and Plone in this regard? Is > Plone 2.5 still targeting Zope 2.8? Yes. > Is CMF? CMF 1.6 is. I hope CMF 2.0 is not. > I heard some mumblings perhaps 2.9 should be targetted. But perhaps > Zope 2.8 is still solidly the target. Perhaps these use cases aren't > driven by Plone/CMF core and some other packages would like to use > this in Zope 2.8? Can they be identified? The general use case is to stop having to put things in Products. When now writing Zope 2 software, a lot of code basically expects stuff to be in Products, Rocky's modifications make that go away and add a ZCML directive to let Zope 2 pick up packages from outside Products (so that they will still receive the same initialization features and an entry in the Control_Panel, etc.). The reason for doing so is simple: Products is bound to go away. It gives a lot of people a lot of pain. With a lot of Zope 3 technology entering many Zope 2 projects, it would be good to get a clean slate early on: put new stuff on Product-less packages. > For simplicity, both for the developers using Five as well as for the > developers building Five, it'd be much easier if we could simply all > agree new features go into Five 1.4 for Zope 2.9. Yes. I agree. I guess the only compelling reason to backport to Five 1.2 is to make people NOT upgrade to Zope 2.9 for this particular feature (product-less packages). Then again, Zope 2.9 is "stable" (people don't really trust a .0 release) and we could release Five 1.4 any time after Rocky is done. So there's really no reason for people NOT to upgrade, I guess. > Then again, I'm not absolutely against continuing the Five 1.2 line with > new features. Me neither. > How to name it is indeed tricky. Perhaps in favor of > comprehensibility we just want to name it 1.2.1, even though we add > new features. While we cheat and add new features to what should be a > pure bugfix release, potentially destabilizing it, I think it's > easier on everyone's mind not to introduce a new line of Five 1.2's > with features. Yes, on second thought I agree. > I also still hope that the pressure to add new features to Five 1.2 > will go away very quickly. Well, in five months we can retire Five 1.0 and 1.2 for good. I do not plan to maintain Five releases any longer than their corresponding Zope releases (others are welcome to do that, of course). Philipp ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Re: [Plone-developers] Re: Re: The components of Archetypes
Hi! Martin Aspeli wrote: > Hi Alec, > > I see that plone_schemas covers most of what I was asking about, which > is great :) > > I took a look at plone_schemas' example type. I can't get it to install > (Zope won't start, some conflict of versions, I'm sure), but looking at > the code, I notice that you > > - Derive from PortalContent > > - Define an FTI dict > > - Define all the DC metadata accessors manually > > - Define a factory method > > - Manually construct an FTI etc. in Install.py > > None of that's rocket science, but I wonder if the framework shouldn't > take care of some more of that. Part of the point would be to insulate > your content types from changes in the underlying stack, e.g. if/when > CMF stops using the portal_types/FTI constructs, for instance. If > that's starting to sound like Archetypes, though, you're right. :) > > So... let's think about what we really *want*: > > - A simple Z3 schema in an interface that defines what my content type > does > > - A component-architecture compatible way of adding behaviour and > other facets via adapters etc. > > - Something that works as a proper CMF and/or Plone (and/or CPS or > whatever) type, that shows up in the add menu, that interacts with > other Plone facilities. > > So - one problem is that there is a lot of Plone software out there > that just assumes all content types are Archetypes. I'd rather not > worry about that just yet, though, because we're not yet at the stage > where we have a realistic general alternative, and with proper > componentisation, fixing up those places where AT is assumed probably > won't be too hard. > > But beyond that, CMF requires a lot of boilerplate, like above, that > I'd rather not have to remember or deal with. So, what are the options? > > - Having the framework inject base classes and code based e.g. based > on certain ZCML directives? > > - Using BaseContent or something similar as a base class? > > - Making a custom base class for plone_schemas-like content that pulls > in whatever CMF needs, but insulates us from future changes? What about code generation? At least for the FTI I would like that because I see more explicitly what is used and I can change it myself afterwards. Same might also be possible with other types of boilerplate. The best way would be anyway to make the components in a way to be used with any of the above solutions. -- christian ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: browser views and memoization
Hi Whit!
whit wrote:
yuppie wrote:
I ended up using this method as decorator for most methods:
def memoize(func):
memo = {}
def memoized_func(*args):
if args not in memo:
memo[args] = func(*args)
return memo[args]
return memoized_func
Are there better ways to resolve this?
Will those memo dicts be removed together with the view object or does
this create a potential memory leak? (I'm not very familiar with
decorators.)
that's pretty elegant compared to shoving a multitude of values into the
view. The closest thing to it would be a PEAK binding, but even that
can't handle the variety of situations that keing the memo by function
signature gives you. very nice.
Besides the fact it doesn't work :(
that looks safe; as far as I can tell when the decorated method is
garbage collected with the view, all refs to 'memo' should be reaped..
Digging a bit deeper it looks like decoraters are created on class
level, not on instance level. So 'memo' is not garbage collected with
the view, it's the same for all instances and grows with each request.
That's not exactly the behavior I want.
Have to think about it a bit more. Any input is welcome.
In python 2.4 you could use frozenset to have keyword support too. I
think something like this would work:
> def memoize(func):
> memo = {}
> def memoized_func(*args, **kwargs):
> sig = (args, frozenset(kwargs.items()))
> if sig not in memo:
> memo[sig] = func(*args, **kwargs)
> return memo[sig]
> return memoized_func
Thanks, I'll keep that in mind. For now this is not my problem.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open jens - "Discussion replies removal", [Accepted] http://www.zope.org/Collectors/CMF/391 - "'CMF Default Workflow [Revision 2]' Extension broken", [Accepted] http://www.zope.org/Collectors/CMF/399 mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 regebro - "fiveactionstool broken (Zope 2.9/3.2)", [Accepted] http://www.zope.org/Collectors/CMF/392 Pending / Deferred Issues - "Wrong cache association for FSObject", [Pending] http://www.zope.org/Collectors/CMF/255 - "CMFSetup: Windows exports contain CR/LF, LF and even CR newlines", [Pending] http://www.zope.org/Collectors/CMF/266 - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Deferred] http://www.zope.org/Collectors/CMF/271 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "CMFSetup: Workflow Tool export fails with workflows which have scripts", [Pending] http://www.zope.org/Collectors/CMF/373 - "CMFCore.Skinnable.SkinnableObjectManager can merge skin data", [Pending] http://www.zope.org/Collectors/CMF/375 - "Proxy Roles does't work for a Script using portal_catalog.searchResults", [Pending] http://www.zope.org/Collectors/CMF/380 - "WorkflowAction deprecated warning should not printed for WorkflowMethod", [Pending] http://www.zope.org/Collectors/CMF/388 - "workflow notify success should be after reindex", [Pending] http://www.zope.org/Collectors/CMF/389 - "came_from and VIRTUAL_URL problem", [Pending] http://www.zope.org/Collectors/CMF/393 - "DCWorkflow - Transition Guards - Documentation Bug", [Pending] http://www.zope.org/Collectors/CMF/394 - "A workflow without managed permission can't be exported", [Pending] http://www.zope.org/Collectors/CMF/397 - "Implicitly acquiring allow_discussion in isDiscussionAllowedFor", [Pending] http://www.zope.org/Collectors/CMF/398 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "path criteria on Topic should honor VHM", [Pending] http://www.zope.org/Collectors/CMF/111 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "Add condition for transition's action like other action", [Pending] http://www.zope.org/Collectors/CMF/207 - "Major action enhancement", [Pending] http://www.zope.org/Collectors/CMF/232 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Deferred] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: RFC: browser views and memoization
yuppie wrote:
> Hi!
>
>
> The skin scripts for complex forms in CMF like folder_contents are
> currently big monolithic blocks of code. All the values needed in the
> template are computed in a predefined order that makes sure expensive
> tasks like querying the catalog or listing folder contents are performed
> only once (per request).
>
> Trying to convert this into a browser view and to split the code in
> several methods I stumbled other the following issue:
>
> If globally needed values are returned by their own method they have to
> be computed again and again, although during the short live of a view
> class they can be considered static.
>
> One option would be to pre-compute those values in the __call__ method
> and to store them in the view object. An other option is to cache the
> results.
>
> I ended up using this method as decorator for most methods:
>
> def memoize(func):
> memo = {}
> def memoized_func(*args):
> if args not in memo:
> memo[args] = func(*args)
> return memo[args]
> return memoized_func
>
This would usable only if all args are hashable. Example:
>>> {}[{1:1},]=1
Traceback (most recent call last):
File "", line 1, in ?
TypeError: dict objects are unhashable
>>> {}[[1],]=1
Traceback (most recent call last):
File "", line 1, in ?
TypeError: list objects are unhashable
>
> Are there better ways to resolve this?
>
> Will those memo dicts be removed together with the view object or does
> this create a potential memory leak? (I'm not very familiar with
> decorators.)
>
>
> Cheers,
>
> Yuppie
>
>
> ___
> Zope-CMF maillist - Zope-CMF@lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
>
> See http://collector.zope.org/CMF for bug reports and feature requests
>
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
