[Zope-dev] Re: egg issues: adding namespace boilerplate Products / patching testrunner
Philipp von Weitershausen wrote: Wichert Akkerman wrote: Previously whit wrote: 2 items: 1. how does everyone feel about adding the following boilerplate to all occurences of Products/__init__.py to enable the easy creation of Product eggs? Aren't we asking people to move to using python packages instead? Well, I certainly hope we're not asking people to rename all of their existing products because that would be a waste of time. This change eases the deployment of existing products as eggs. I'm -1 on requiring such changes to Products. I think you're misunderstanding the issue at hand. Nobody's products will have to change. Zope's lib/python/Products/__init__.py will change. exactly... and python packages don't quite work right all the time(like that wierd bug with directory views and ZEO). -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 ___ 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] egg issues: adding namespace boilerplate Products / patching testrunner
2 items:
1. how does everyone feel about adding the following boilerplate to all
occurences of Products/__init__.py to enable the easy creation of
Product eggs?
try:
__import__('pkg_resources').declare_namespace(__name__)
except ImportError:
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
2. Could we consider this a defect so it could be added to relavent
maintenance branches(provided no one sees any harm in #1. I mainly care
about zope 2.9)
3. daniel nouri has made a patch for the test runner to enable a flag
optionally add all packages on your path to the test search path. I
consider this a defect in the current test runner that makes working
with eggs and 2.9 or 2.10 rather cumbersome. could we consider adding
this or some other solution to this problem?
http://www.zope.org/Collectors/Zope/2276
-w
--
-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org -
- m: 415-710-8975 -
If you don't know where you are,
you don't know anything at all
Dr. Edgar Spencer, Ph.D., 1995
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Interest in AdvancedQuery and/or ManagableIndex?
Philipp von Weitershausen wrote: Dieter Maurer wrote: yuppie wrote at 2007-2-3 11:44 +0100: ... Unfortunately integrating a product into the Zope core means more than just adjusting the coding style: - As already mentioned in this thread, monkey patches and code like fixPluginIndexes.py have to be resolved. AdvancedQuery contains a monkey patch for CMF - that should not be shipped with Zope core. fixPluginIndexes fixed (maybe meanwhile resolved) bugs in Products.PluginIndexes.common.util.parseIndexRequest. The mentioned CMF monkey patch gives the CatalogTool the new method evalAdvancedQuery, provided CMFCore is installed. I do not see why this monkey patch should not be applied. I am sure that I want to be able to use AdvancedQuery even with a CatalogTool, if both are installed. Monkey patches should be avoided when they can. I think that's something we don't need to discuss. Integrating a product into Zope is the perfect opportunity to get rid of monkey patches and consolidate the fixes into the main product lines. Therefore, the CMF should rather grow that method itself than having it patched in by Zope. Either way, I think this point is mute since all the Plone community really wants is a public subversion repository with access to the code and control over the code, which I would think is asking for a lot (you've indicated that reformatting the code would mean you wouldn't be available for maintenance anymore). Whoever is asking for AdvancedQuery and other things to be in svn.zope.org or even Zope 2 itself ought to weigh the amount of maintenance work against the little potential (not actual!) benefits. I think we can leave everything as it is and if Plone needs it in an svn repo, heck, why not do vendor imports? (not in svn.zope.org, of course, since the contributor agreement forbids that) I'm not sure this warranted this much discussion or getting panties in a bunch, but maybe something was learned here. As phrased early on, it would be *nice* for those of us using svn:externals to manage certain build processes to have AdvancedQuery in svn somewhere(not life or death). did we reach some sort of conclusion in all this? Having a AQ egg would be the same difference imho. I would be happy to help maintain AdvancedQuery(though I hardly feel qualified), though I would prefer to leave it in a form that Dieter would actually want to work on it. What might be more worthwile is to package AQ up to be an egg(I volunteer for this). That way we could manage the dependency that way(zope could too if it chose to ship with AQ), dieter could continue maintaining AQ, and everything would be peachy. one last point re: Zope: From a marketing perspective(to parrot slinkp), I would think Zope 2 would want to include AdvancedQuery since it is a go-to answer for lots of how do I do sqlish query X in the ZODB type questions. Granted, hurry.query and the z3 catalogs have similar capabilities, but AQ works right now with existing z2 catalogs. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 ___ 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] Re: RFC: Eggifying Zope's extension mechanism (Products)
Philipp von Weitershausen wrote:
Rocky Burt wrote:
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote:
I do wonder what would happen if you had both
lib/python/Products/CMFCore
and Products/CMFCore, though. Would there be an explicit preference
or would
Zope fail to start up with a conflict? I think I'd prefer the latter, in
fact, so that people don't end up modifying/upgrading the wrong code by
accident!
Well, we could probably add conflict-detection to the entry point
handlers for Zope (ie so any two packages that try to register as the
same project would cause an error). But regarding Products/CMFCore and
lib/python/Products/CMFCore conflicting... that would be up to the
standard pythonpath mechanism of the python interpreter (whichever is
first on the path wins).
Zope 2 itself manipulates Products.__path__ to add INSTANCE/Products (or
any other directory specified in zope.conf) as a directory which can
contain further products (the original Products package lives at
ZOPE/lib/python/Products). pkg_resources uses the same mechanism for
namespace packages (that's what the
pkg_resources.declare_namespace('Products') call is all about); it
appends to __path__.
Therefore, Zope will treat /path/to/the/CMFCore-egg/Products as another
directory that contains a product (in this case just one, CMFCore). Thus
the standard product override rules apply when the same product is
installed in multiple directories.
I updated the proposal text with this information.
I imagine it would be pretty trivial to write something that would
generate a setup.py from an svn:externals property so you could create a
Products distribution in one fell swoop, especially since the entry
point section of the setup.py can handle config parser output.
-w
--
-- d. whit morriss --
- senior engineer, opencore -
- http://www.openplans.org -
- m: 415-710-8975 -
If you don't know where you are,
you don't know anything at all
Dr. Edgar Spencer, Ph.D., 1995
___
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] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Jim Fulton wrote: whit wrote: I'm not clear on what the advantage would be. I'm probably missing some use cases. I think they are both valid approaches to the problem. my main usecase is to be able to use buildouts in a workingenv without having to rewrite the recipes... right now, I have to do one or the other. Sure. I still don't know what that means. :) *Maybe* you'd like to use workingenv to install eggs and use buildout to do other things like set up zope instances. If that's the case, then it's just a matter of writing recipes that take into account how you install eggs and scripts. But maybe that's not what you mean. ... If people really see value in having buildout and workingenv work together, perhaps Ian and I could explore this a bit at PyCon next month. +1. my general feeling is that there is a enough overlap that this would be beneficial. Specific use cases would help to guide this. the main usecase for me is the following... hanno writes a recipe for plone, and I want to use that recipe as part of setting up a openplans development environment (for example inside my workingenv that I've been developing w/out plone). I'd like with minimal effort to have build in my setup without having to dig too deep into the existing buildout or the framework driving it. This might be as simple as having buildout(at my own risk), do less with creating special pythonpaths in scripts(or perhaps just appending the existing one as the zope2 zopectl script does now). I'd also like to have the development eggs and normal eggs go where I currently have my eggs(lib/python, /src). as I believe you've pointed out that can be done by simple modification of the cfg file and that'd be fine. try to justify why a zope hammer is better and why zope folk keep building new hammers that don't play nice with everyone else's hammer loses us cred. You seem to be implying that workingenv is somehow a standard tool and that buildout is a zope-specific tool that needlessly duplicates a standard tool. I was perhaps offbase in my comment about egg handling. workingenv of course is not a standard tool. what I'm presenting here is a perspective I face on a regular basis; for a developer using workingenv already, it's far more standard than something else he is not using...and vice versa. No, it's more familiar -- to these people. actually, in my current workplace, workingenv is the standard way to set up one's dev environment. but in the context of the previous statement, familar is perhaps a better word. in the case of tools that enable a developer to start quickly, developers are very difficult to ween from habits that are currently working. when a large and complex task such as building plone becomes codified in a technology that is not familar or easily compatible with the the developers current environment, it's an issue. The alternative seems to be a custom shell script. I can see how this would be familiar to the people who wrote it. When there are well established and documented buildout recipes for doing common tasks, then there will be familiar tools, for some definition of familiar. this is where rob started with our deployment strategy. I like buildit and buildout's codification of what happens in a build in cfg file since it creates a fairly auditable place to see what is happening(as well as extend it). we are going to re-write the shell scripts using buildit and if plone uses zc.buildout, would like not to have to replicate that part in our own system. zc.buildout is in no way zope specific. Can a Zope developer not develop a tool without it being stamped as zope specific? maybe... maybe not. When a developer struggles with more than one tool from the same general source, it matters little to them whether one depends on the other or not. That's true for languages, companies, frameworks and everything else. I think it really depends whether something transcends it's immediate community(and maybe here whether a z floats in front of it's name somewhere). So lets see. To contribute to the wider Python community, I should change the name of my Company or change jobs. Hm. for packages from zope or plone people, if they rides roughly with existing python techs In what way does buildout ride roughly with existing python techs. It builds on setuptools. Do you mean that if there is another community package that does something somewhat similar, we aren't allow to create a similar package just because we are associated with the Zope project. and come from a zopeish repository, Oh, I have to use a different repository. sadly they are liable to get branded w/ a legacy reputation that haunts the name. Has it occurred to you that the problem here doesn't lie with the Zope project or Zope developers? inversely, those of us zope and plonistas may be a bit uncritical of projects coming from close to home Oh, as someone
[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Philipp von Weitershausen wrote: whit wrote: Martin Aspeli wrote: Philipp von Weitershausen wrote: This is awesome, and by that I don't mean the fact that we have a plone buildout, but that we actually have Zope 2 recipes for buildout. I hope they can be moved to svn.zope.org for further development to benefit the whole Zope 2 community. I believe this is just a matter of contrib agreements being sorted out (Hanno?). I guess I need to get mine sorted out as well if I'm going to keep working on this when it moves... :-/ I also see that workingenv was abandoned. That's very good to hear because buildout has a lot of machinery for installing eggs already, it would just've been duplicated with workingenv... is there some advantage to the way that buildout handles eggs over workingenv. as I understand it, workingenv *only* handles python setup and does that well and transparently. The point is that buildout *already* handles eggs. There's really no point for having an extra layer on top of buildout. The zc.recipe.egg recipe can install any egg (as a development one or not) in an automated fashion, which is exactly what you'd want from a buildout. well that's awesome that buildout has duplicated this effort the source bin/activate dance is the only thing I see being a detriment here(and with the latest workingenv, your shell prompt lets you know you are in an env). Not everybody likes the activate dance. With buildout, you don't need it. The recipes make sure that the scripts that get installed into the buildout's 'bin' directory have the right PYTHONPATH set and have access to the eggs you requested for the buildout. is there really a difference between zopectl and source bin/activate? I guess the main difference here is where PYTHONPATH gets set and how people work with it. for example, if you just start python and want to play with code sounds like with zc.buildout you are out of luck for things installed in the buildout. In our situation, we might have multiple versions of software running on different processes started in different workingenv (often not even using zope).being able to contextualize the python path is a useful development tool; this is understandable for buildout to avoid(as a deployment tool), but if we are considering using buildout as a prescribed way for people to manage their development environments, it seems lacking. Workingenv made it more complex than it needed to be (or buildout did, depending on which perspective you look at it from). I believe Hanno wanted to rescue the recipe in case others found it useful, but it's not used for now. what about if I'm already using workingenv... and want to use zope or plone in my workingenv? I see no problem with that. zc.buildout is one way of deploying Python software like Zope. As long as you've got eggs, you could install them manually into your workingenv just fine. buildout just does it an automated fashion (and, of course, it can do more than just installing eggs). which I could automate in my env (workingenv takes recipes also). for that matter, eggs automate the installation of eggs... I'm not sure what it would take to make buildout just automate install eggs into my env... but not putting them in special directories would be a start. currently, I don't see an easy way to use buildouts inside a workingenv, whereas the rest of python world works great. I will have alot of trouble explaining to my developer who already think zope smells that they have to change the way they work to use zc.buildout recipes. for example, I can't use the deliverance or lxml buildout with an existing topp.deploy workingenv because of buildout's arbitrary egg handling scheme. If zc.buildout didn't try to do so much, the python would be installed transparently like everything else I easy_install. I'm not too fond of zc.buildout's directory scheme eiher. In particular, I wish that it would use 'lib/python' instead of 'eggs' and 'src' instead of 'develop-eggs'. I don't know enough zc.buildout details to be able to say whether that can be chagned by remimplementing the egg installation recipe. I would sure hope it is. +1 this may be all that is required to make the two play well together(or have buildout respect an existing workingenv when doing it's local install of eggs). Maybe it's just a matter of zc.buildout seeing workingenv is in effect and not composing special pythonpaths. harmony is my interest here. workingenv is pretty low-level and works hard to work well with python. there is no reason that zc.buildout should have a problem with that.. it just needs to do less when appropriate. as stated before, I don't mind using zc.buildout, but I don't want to have to learn zc.buildout to use it meaningfully in my existing setup. If a buildout recipes could be executed by themselves(like buildout-zope2, buildout-deliverance, buildout-squid
[Zope-dev] Re: ZCML and 'zopectl test'?
I just made ZopeTestCase defer all loading until it's layer(essentially deferring the import of ZopeLite which is sort of a subpar way to handle things and using a registry to handle installProducts). most of what happens in zopelite itself should be the layer(rather than carefully isolating the import) http://svn.zope.org/Zope/branches/whitmo-2.10-layers/ lurker, comments? from what I remember, the only issue was with the sandbox tests(for functional tests). basically in sandboxed test you need a fresh zodb for each test iirc. -w ___ 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] Re: [z3-five] RFC: The future of Products.Five
Andreas Jung wrote: --On 31. Oktober 2006 02:56:39 +0100 Philipp von Weitershausen [EMAIL PROTECTED] wrote: Andreas Jung wrote: What are our benefits from a Z2 Eggification. Eggification is basically about packaging and distribution of components with little dependencies in order to re-use them in other contexts. However most components of Zope 2 are heavily dependent on others. Yes, that's true. But eggs don't necessarily have to have few dependencies ;). Eggs just have well-defined dependencies. And like Whit said, there might be a desire to have certain Zope 2 components have a faster life cycle than others, e.g. ZopeTestCase in Whit's case. Yeah, it would make sense for particular components but not for all components just for the sake of eggs. -aj I would expect things to move as needed rather than just for the sake of it. -w ___ 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] Re: RFC: The future of Products.Five(green eggs and zope)
Philipp von Weitershausen wrote: snip / I don't think all of these things should go into the Products.Five anymore, for several reasons: * We're trying to get away from writing products and into writing Python packages that can e.g. be installed as eggs. * Some of these things are not essential to bringing Zope 3 technology into Zope 2 (e.g. like the intid stuff), so it may be questionable whether it should ship with Zope 2/Five out of the box. * Starting with Zope 2.10, Products.Five is actually getting smaller which is a trend I would like to continue to see. And if I manage to land my Acquisition refactoring in 2.11, Products.Five will pretty soon decrease in size tremendously, and there are also other things in Products.Five that should really be in Zope 2 proper (e.g. OFS). +1 to this logic Proposal So, what I'm proposing is to feature-freeze the Products.Five package and just basically keep making it work for future Zope versions. Five 1.6 (current trunk) will work for Zope 2.11 (current trunk), Five 1.7 for 2.12, etc. So, essentially there won't be Five feature releases in between anymore, which means we can put Products.Five into the Zope/lib/python/Products proper. New stuff will be added in standard Python packages that may or may not ship with Zope 2, Plone or whoever needs them. I personally almost don't care, it's really only about defining the right egg dependencies in Plone 3.0 or Zope 2.11, I would assume (see also 'Risks' below). This seems like the release manager's job who would include stuff based on requests from the community and package maintainer's recommendations. The namespace for these packages should probably be 'five', as we already have five.intid and five.customerize and we are, after all, the Five project. +1 Advantages -- * We'll be able to use stuff we get for Python packages for free, such as installation via eggs, Cheeseshop presence and much less majyck for initialization. * Stuff that we create as part of the Five project does not necessarily have to end up in Zope 2. Currently, stuff added to Products.Five eventually always ends up in some Zope 2 release which means we'll have to maintain it forever, no matter how crappy it turns out to be (e.g. Products.Five.site). flipped around, it would be nice to see the crufty features in Five moved out to their own packages, to enable BBB *if needed*. this is similar to nuxeo's XYZonFive product pattern, but easy_install-able. * Development of certain components can move much faster than even Five. New things like five.intid or five.customerize can be experimented with and already be in the right place if they turn out to be stable. If not, they won't harm Products.Five, either. Individual packages rather than one big one also reduces the amount of work that has to be done by the Five release manager (IOW my work ;)). would like to note that other packages in Zope2 also need this ability to release asynchronously from Zope2's schedule; ZopeTestCase in particular comes to mind(Testing should be a namespace package imho). Risks - * If five.* packages need ZCML config (and I know some will), they will either have to be included the Zope 3 way (site.zcml or package-includes slug in your instance's 'etc' directory), or we need to come up with an approach that Zope 2 people are more comfortable with. I think an egg entry point would be a compelling solution. big +1 here. would love to use paste deploy to configure my zope instance. There are plans to do this in Zope 3 even so that you can provide configuration from Python instead of ZCML. I expect this to land in Zope 3.4 which means we should be able to take advantage of it in 2.11. I will defer to other's here but say this: I'd rather have better tools to configure with than more options in the configuration language. * It is unclear to me at this point what Zope 2's egg story will be. I *hope* that 2.11 will get the same egg story as the Zope 3.4 that ships with it does, though noone has talked about eggifying Zope 2 yet. We should probably do that. re zope2 egg story: some talk has occurred thanks to goldegg and general irritation suffered by myself, rocky, nouri and others. Tres and McDonc have definitely plumbed the ugly depths of zope2 thinking about this problem for goldegg. Nouri has run the plone stack as an egg; I've run Zope2 as an egg. re my experience, I made a somewhat indecipherable post about my experiences with easy_install-ing zope from svn with workingenv. To reiterate, the results are pretty cool: all of zope is installed into your workingenv/lib/python, all your scripts(repozo, mkinstance, etc) are installed into your workingenv/bin . Some minor edits are required to make the scripts find the proper libs(due to SOFTWARE_HOME path expectations) and the site skeleton disappear but really, it's darn close to working as an egg.
[Zope-dev] Re: [z3-five] RFC: The future of Products.Five
Andreas Jung wrote: --On 30. Oktober 2006 00:01:33 +0100 Philipp von Weitershausen [EMAIL PROTECTED] wrote: * It is unclear to me at this point what Zope 2's egg story will be. I *hope* that 2.11 will get the same egg story as the Zope 3.4 that ships with it does, though noone has talked about eggifying Zope 2 yet. We should probably do that. What are our benefits from a Z2 Eggification. Eggification is basically about packaging and distribution of components with little dependencies in order to re-use them in other contexts. However most components of Zope 2 are heavily dependent on others. Or are we talking about using Zope 3 eggs within Zope 2 as part of the Zope 2 distribution process? I would argue a bit of both. Zope 2 can be a giant egg without much difficultly enabling use of easy_install and dependency management in relation to that egg(think of how products depend on a version or point version of zope2). As an egg friendly installable, it can then be used in egg recipes etc. it also lets us start teasing parts of zope2 out of the monolith of zope2 their own eggs(ZTC comes to mind) so they can evolve at a rate not controlled by the zope2 release process. Since it is possible to match dependencies, releases can be built from egg recipes dynamically rather than cumbersome bundle linking. I'm guessing this would make release management ultimately easier and more consistent; a recipe would simply match all stable and compatible eggs to the zope version that needed them. -w ___ 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] Re: PYTHONPATH
Sidnei da Silva wrote: On Mon, Oct 16, 2006 at 11:49:14AM -0500, whit wrote: | http://www.zope.org/Collectors/Zope/2206 is resolved for *nix | flavors(sorry for double posting, completely forgot I had posted the bug | before). I have no access to a win box so someone else will need do the | necessary changes to the bat files in skel(if this sort of thing is even | possible on windows). Of course it is. Just use '%PYTHONPATH%' instead of '$PYTHONPATH'. While on the subject, I had asked about adding $INSTANCE_HOME/lib/python as well. No one seemed to object. Do you mind making this extra change while you're at it? This one should come before everything else in PYTHONPATH. $INSTANCE_HOME/lib/python:$SOFTWARE_HOME:$PYTHONPATH sounds good to me -w ___ 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] Re: PYTHONPATH
http://www.zope.org/Collectors/Zope/2206 is resolved for *nix flavors(sorry for double posting, completely forgot I had posted the bug before). I have no access to a win box so someone else will need do the necessary changes to the bat files in skel(if this sort of thing is even possible on windows). -w whit wrote: silence == consent. will proceed as declared. -w whit wrote: Paul Winkler wrote: On Wed, Sep 27, 2006 at 06:26:49PM -0500, whit wrote: It seems like if you've set your PYTHONPATH and start zope, you would expect that path to be available. Indeed. Anyone object to this going forward? Anyone think this is a bug that should be fixed(on older versions)? I think it's a bug, but then, I don't recall ever stumbling on it in practice. alright... if noone objects, I'm filing this as a bug and making the change. will wait another 24 hours. -w ___ 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 ) begin:vcard fn:david morriss n:morriss;david org:The Open Planning Project email;internet:[EMAIL PROTECTED] title:Senior Engineer url:http://www.openplans.org version:2.1 end:vcard ___ 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] Re: PYTHONPATH
silence == consent. will proceed as declared. -w whit wrote: Paul Winkler wrote: On Wed, Sep 27, 2006 at 06:26:49PM -0500, whit wrote: It seems like if you've set your PYTHONPATH and start zope, you would expect that path to be available. Indeed. Anyone object to this going forward? Anyone think this is a bug that should be fixed(on older versions)? I think it's a bug, but then, I don't recall ever stumbling on it in practice. alright... if noone objects, I'm filing this as a bug and making the change. will wait another 24 hours. -w ___ 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 )
[Zope-dev] Re: Zope 2.10.0 released
thanks guys...know this one was a long time in the coming. -w Andreas Jung wrote: Hi all, on behalf of Zope developer community I am pleased to announce the release of Zope 2.10.0. You can download Zope 2.10.0 from: http://www.zope.org/Products/Zope/2.10.0/ Some new features of Zope 2.10: - ZPT implementation based on Zope 3 - experimental WSGI and Twisted integration - Zope 3.3, Five 1.5 integration - clock server - lots of minor improvements and fixes - replaced several Zope 2 modules with their sister implementation of Zope 3 For more information on what is new in this release, see the CHANGES.txt files for the release: http://www.zope.org/Products/Zope/2.10.0/CHANGES.txt Please bring all the bugs you have found to the Zope bugtracker: http://collector.zope.org/Zope For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: http://www.plope.com/Books/2_7Edition/InstallingZope.stx Supported Python versions: Zope 2.10 requires Python 2.4.3 (Python 2.4.2 is still acceptable). Older Python versions are no longer supported. Using Python 2.5 is also *unsupported*. Many thanks to all everyone who contributed. Very special thanks go to Philipp von Weiterhausen for his continuous and outstanding work in the Zope 2 *and* Zope 3 world. ___ Zope-Announce maillist - Zope-Announce@zope.org http://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: http://mail.zope.org/mailman/listinfo/zope Developers: http://mail.zope.org/mailman/listinfo/zope-dev ) ___ 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] Re: PYTHONPATH
Paul Winkler wrote: On Wed, Sep 27, 2006 at 06:26:49PM -0500, whit wrote: It seems like if you've set your PYTHONPATH and start zope, you would expect that path to be available. Indeed. Anyone object to this going forward? Anyone think this is a bug that should be fixed(on older versions)? I think it's a bug, but then, I don't recall ever stumbling on it in practice. alright... if noone objects, I'm filing this as a bug and making the change. will wait another 24 hours. -w ___ 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] Re: In Defense of ZClasses
if zclasses(and some of the niceties that depended on them like ZPatterns) could reliably roundtrip to the filesystem, would we be having this conversation? I don't know...it seems like if you tackled the less sexy problem of making zclasses play with normal developer tool chain, the divide between zclass fans and core developers is bridged. Seaside, the smalltalk web framework is a successful example of this(but before it could be, they had to build a scm in smalltalk). I think the reality is that since the current best practice toolchain came after the inception of ZClasses, you can't expect any active developers to want to maintain something divorced from their working environment. bring zclasses back to the tool chain, and you might grow an audience to help you. -w ___ 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] Re: ZClass Maintenance
ZClasses don't get better from writing long postings. Ah, yes but I can write much faster than I can code. What am I doing on this list!?! All I have to do is to motivate someone else to do the work! programmers are generally motivated by concrete contributions ie money, code, beer, or trips to exotic places to get money, code, or beer. hope that helps, -w ___ 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] Re: A Quick Event-based Cataloging How-to for Zope 2
thanks Chris!
-w
Chris Withers wrote:
Hi All,
Just been playing with this and found it remarkably easy, so thought I'd
pass it on. If anyone can think of a better place than the mailing list
archives for this, please let me know!
Anyway, so I'm building a Zope 2 app where I need to index objects that
are not catalog aware when they're added, modified or removed. To make
things harder, this also needs to work via WebDAV.
OK, so here's the solution:
1. Create yourself a python module called subscribers.py and put it on
your python path, containing the following:
from Acquisition import aq_base
from zope.interface import Interface
class ICatalogAware(Interface): pass
def catalog(object,event):
if aq_base(object) is object:
# ObjectModified can get emitted during creation,
# before the object has any acquisition context
return
object.getPhysicalRoot().unrestrictedTraverse(
'/catalog'
).catalog_object(object)
def uncatalog(object,event):
object.getPhysicalRoot().unrestrictedTraverse(
'/catalog'
).uncatalog_object('/'.join(object.getPhysicalPath()))
2. Slap the ICatalogAware marker interface on any classes you want to
have indexed. Here's an example for the good old File object. Put the
following in your site.zcml:
class class=OFS.Image.File
implements interface=subscribers.ICatalogAware/
/class
3. Finally, wire up the events so that files get indexed when they're
created, modified or removed, again by adding the following to site.zcml:
subscriber
handler=subscribers.catalog
for=ICatalogAware
zope.app.container.contained.ObjectAddedEvent
/
subscriber
handler=subscribers.catalog
for=ICatalogAware
zope.app.container.contained.ObjectModifiedEvent
/
subscriber
handler=subscribers.uncatalog
for=ICatalogAware
zope.app.container.contained.ObjectRemovedEvent
/
4. Okay, sadly you do need to get do some patching if you want changes
to the file to result in recataloging :-/ Here's a diff:
--- Image.py.original 2006-09-26 16:32:20.759375000 +0100
+++ Image.py2006-09-26 16:33:11.384375000 +0100
@@ -33,6 +33,8 @@
from ZPublisher.HTTPRequest import FileUpload
from ZPublisher.Iterators import filestream_iterator
from zExceptions import Redirect
+from zope.event import notify
+from zope.app.container.contained import ObjectModifiedEvent
from cgi import escape
import transaction
@@ -437,6 +439,7 @@
self.ZCacheable_invalidate()
self.ZCacheable_set(None)
self.http__refreshEtag()
+notify(ObjectModifiedEvent(self))
def manage_edit(self, title, content_type, precondition='',
filedata=None, REQUEST=None):
Okay, well, hope this helps someone :-)
Chris
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] PYTHONPATH
I've been working with workingenv.py and zope a bit. It offers a very nice fashion of working with zope(constrains python and setuptools to operating in a restricted environment). there are some lumps. you have to call the --home flag when creating the environment. I haven't successful made a zope checkout in to a workingenv itself. those are small potatoes. More pressing is that currently to make this work, you have to hand edit bin/zopectl and bin/runzope like so:: PYTHONPATH=$SOFTWARE_HOME to: PYTHONPATH=$SOFTWARE_HOME:$PYTHONPATH Would there be any negative sideeffect to make this change the default in the instance skeleton? It seems like if you've set your PYTHONPATH and start zope, you would expect that path to be available. Anyone object to this going forward? Anyone think this is a bug that should be fixed(on older versions)? comments, suggestions appreciated. -w ___ 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] Re: Adding INSTANCE/lib/python to PYTHONPATH
Sidnei da Silva wrote: Looks like INSTANCE_HOME/lib/python is added to PYTHONPATH at some point during startup, but not on the zopectl/runzope scripts. I've tried installing eggs into INSTANCE_HOME/lib/python and they won't load unless it's added to PYTHONPATH at startup time. Thus, I propose to add INSTANCE_HOME/lib/python to PYTHONPATH on the said scripts. Anyone against making this change all the way down to Zope 2.9? we've also seen a need to add an arbitrary path to PYTHONPATH in these script for situations like using ian bickings workingenv. workingenv constrains the execution and installation environment to an arbitrary directory(no more installing eggs into the site-packages). Might be nice to have this as an option for mkinstance; maybe --home to make it similar to disutils? -w begin:vcard fn:david morriss n:morriss;david org:The Open Planning Project email;internet:[EMAIL PROTECTED] title:Senior Engineer url:http://www.openplans.org version:2.1 end:vcard ___ 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] the zope, eggs and the testrunner
I've been developping some packages using zope.testing and the testrunner that ships with zope2.10. Yesterday, I packaged these using fairly standard python/egg pattern. one package is pure python, the other a zope2/zope3 hybrid. now I have two large PITAs: 1. in general, this would suck alot less if easyinstall would recognize I already have package x, y, and z on my PYTHONPATH, rather than helpfully installing incompatible ones or erroring out when it can't resolve zope dependency x from the ether. Doesn't seem to be a --stop-sucking flag that I can find. removing all the zopeish things like zope.interface and zope.testing solves this problem for the pure python package (but sort of make things like testing interfaces out of the question). 2. zopectl test doesn't see my tests with said packages installed in develop mode or as eggs (assorted --path etc options don't seem to help). Running the tests via python setup.py test only works when I unflag the testing dependency of zope.testing. anyone been down this rabbit hole? have any suggestions? resources? -w -- | david whit morriss | | contact :: http://public.xdi.org/=whit If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 I like to write code like other ppl like to tune their cars or 10kW hifi equipment... Christian Heimes, 2004 ___ 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] Re: SVN: Products.Five/trunk/ Five now requires site.zcml to live in /etc
there is a world of difference between shipping with and requiring...is this language really what happened? I thought the decision was to ship with a site.zcml and package-includes directory in their conventional place, not changing Five's behavior to look for it's skeleton if it didn't find the aforementioned. -w Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: Log message for revision 68359: Five now requires site.zcml to live in /etc Changed: U Products.Five/trunk/CHANGES.txt D Products.Five/trunk/skel/ U Products.Five/trunk/zcml.py -=- Modified: Products.Five/trunk/CHANGES.txt === --- Products.Five/trunk/CHANGES.txt 2006-05-29 19:42:51 UTC (rev 68358) +++ Products.Five/trunk/CHANGES.txt 2006-05-29 20:24:13 UTC (rev 68359) @@ -8,6 +8,18 @@ Restructuring - +* Zope 2.10+ now includes site.zcml as part of its instance creation + skel directory. As a consequence Five now requires this file to exist + in every instance. If upgrading a site from Zope 2.9 to 2.10, you will + need to copy site.zcml and package-includes/ from your installed Zope + installation location (skel/etc/) into the etc/ directory of your upgraded + instance. + + The rationale for requiring this new file is to bring Zope 2 instances + closer in consistency to Zope 3 instances. It also eases use of Zope 3 + coding techniques in Zope 2 and removes some confusion when trying + to run pure Zope 3 applications on Zope 2. This is a BBB foul. The appropriate way to make such a change is to add a deprecation warning, leaveing the old behavior (which was to use the 'site.zcml' from inside Five) in place. Making forward compatibility smoother is *less* important than preserving backward compatibility. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfHlq+gerLs4ltQ4RAlNbAJ9IISl/plYHaMXb7DuEEEvVMJu9pwCeMASk R/kuYOm5U9F03unBpcApm58= =hehK -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 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 )
