Re: [Zope3-Users] Eggs and classic instance homes, again... (was Re: Eggs, workingenv.py, and 'classic' instance homes)
On Wed, 2007-11-07 at 21:22 -0700, Jeff Shell wrote: > On Nov 7, 2007 7:53 PM, Darryl Cousins <[EMAIL PROTECTED]> wrote: > > Hi Jeff, > > > > I hope that this might at least give you the optimism you appear to be > > lacking. > > Thank you. That does give me a much more clear starting point. I was > having a hard time seeing all of the recipes come together. Cheers Jeff. A note about pinning down the versions, I'm following this: http://mail.zope.org/pipermail/zope3-users/2007-November/007106.html now rather than using the grok versions. I didn't have any trouble at all resolving deprecation and import errors when upgrading from Zope3.3.0 tarball to the 3.4 eggs as described in the above mail. There were hardly any compared with the upgrade from 3.2.0 to 3.3.0. Application is up and running on eggs. Brrroook. Regards, Darryl > > As for optimism... We'll see. :) But this was the step I could never > make work (getting a buildout-managed instance up and running) before > running out of time. Thanks again. > ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Eggs and classic instance homes, again... (was Re: Eggs, workingenv.py, and 'classic' instance homes)
On Nov 7, 2007 7:53 PM, Darryl Cousins <[EMAIL PROTECTED]> wrote: > Hi Jeff, > > I hope that this might at least give you the optimism you appear to be > lacking. Thank you. That does give me a much more clear starting point. I was having a hard time seeing all of the recipes come together. As for optimism... We'll see. :) But this was the step I could never make work (getting a buildout-managed instance up and running) before running out of time. Thanks again. -- Jeff Shell ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Duplicate emails from mail queue
On Mon, 2007-11-05 at 17:20 +1300, Darryl Cousins wrote: > Hi, > > On Sun, 2007-11-04 at 22:41 -0500, Benji York wrote: > > Darryl Cousins wrote: > > > Has anyone experienced duplicate emails being sent using > > > IQueuedMailDelivery? > > > > We've seen this when you have more than one process (or thread) > > attempting to deliver messages from a single maildir. I've recently > > made changes on the zope.sendmail trunk to eliminate the duplicates. I > > need to do another release, maybe tomorrow. If you want to try the fix > > before a release is made, you can try running a trunk checkout. > > > Thanks Benji. I don't have time to try the trunk today, will keep an eye > out for the new release. Hi Benji, Initial tests seem to show that the problem is solved using the trunk. Regards, Darryl > > Best regards, > Darryl > > ___ > Zope3-users mailing list > Zope3-users@zope.org > http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Eggs and classic instance homes, again... (was Re: Eggs, workingenv.py, and 'classic' instance homes)
Hi Jeff,
I hope that this might at least give you the optimism you appear to be
lacking.
I've been migrating a complex project which was running on Zope-3.2
tarball install.
My first step was to get it all into a buildout. buildout.cfg looked
something like this [1]. I've missed out lots here (postgresql, lxml,
sqlos, sqlobject, psycopg2, pyro, zif.jsonserver amongst others). Note
that I have included a local install of python in parts to keep things
clean and tidy.
Second step was to upgrade to Zope-3.3 - this just meant changing the
url in the zope3 section. An hour or two of fixing deprecation warnings
(really only deprecation stuff, nothing major).
Step Three, where I'm at now, is to change the buildout to use Zope-3.4
eggs, and Paste. Zopeproject buildout.cfg and other files could provide
you a starting point. I'm using
http://grok.zope.org/releaseinfo/grok-0.10.2.cfg to pin down versions.
See http://grok.zope.org/releaseinfo/readme.html for info on using this
file.
I haven't got the server running yet, but then I've only just finished
getting buildout.cfg right, and all parts built.
In all there has been several hours work so far, but that includes
sorting out the additional dependencies (postgresql etc). Before the
buildout the whole application was a nightmare to install. Now its
looking sooo much better.
I would skip step two if I did this again, although I imagine there will
be a lot more import and deprecation errors to correct.
Hope that helps.
Regards,
Darryl
[1] buildout.cfg
[buildout]
index = http://download.zope.org/ppix
develop = .
parts = zope3
server
instance
database
test
projectpackage # the application code
find-links = http://download.zope.org/distribution/
download-cache = cache
eggs-directory = eggs # keeping this install fully separate from others
develop-eggs-directory = develop-eggs
[zope3]
recipe = zc.recipe.cmmi
url = http://www.zope.org/Products/Zope3/3.2.0/Zope-3.2.0.tgz
extra_options = --with-python=${python:location}/bin/python
--force
[server]
recipe = zc.recipe.egg
eggs = ${projectpackage:eggs}
[instance]
recipe = zc.zope3recipes:instance
application = projectpackage
zope.conf = ${database:zconfig}
[database]
recipe = zc.recipe.filestorage
[test]
recipe = zc.recipe.testrunner
eggs = ${projectpackage:eggs}
extra-paths = ${zope3:location}/lib/python
working-directory = ${buildout:directory}/test
defaults = ['--tests-pattern', '^f?tests$',
'-v'
]
[projectpackage]
recipe = zc.zope3recipes:app
eggs = ${interpreter:eggs}
site.zcml = # all zcml defined here
[python]
recipe = zc.recipe.cmmi
url = http://www.python.org/ftp/python/2.4.4/Python-2.4.4.tar.bz2
executable = ${buildout:parts-directory}/python/bin/python
extra_options = --with-threads
--with-readline
--enable-unicode=ucs2
[interpreter]
recipe = zc.recipe.egg
eggs = setuptools
# list-of-eggs: lxml, sqlos etc, etc
interpreter = python
extra-paths = ${buildout:parts-directory}/zope3/lib/python
On Wed, 2007-11-07 at 17:24 -0700, Jeff Shell wrote:
> The last time I was active on this list was back in mid-august. I was
> fighting an uphill battle to try to figure out how to migrate our
> software to 'Eggs'. I ultimately had to abandon the process as there
> was just too much real work to be done, and I was getting conflicting
> answers about how to move forward. Actually, I couldn't get much help
> from the community at all. I apologize for the crankiness of this
> email. The last time I tried to get help on this topic was an
> excercise in sheer frustration. Since then, the gulf I've worried
> about seems to have gotten even bigger, and I'm feeling very stressed
> right now.
>
> So now I see all that's going on with Zope 3 and I still don't
> understand a thing about how to move forward. We have about twelve
> active customers deployed on Zope 3, on top of one or two large
> frameworks that we've built on top if Z3. We still use the basic
> 'instance home' layout. We don't use eggs - we just check things out
> directly into the instance home. Even stuff from the Zope community,
> because it's easier to do that than to even get workingenv or any of
> these other things running.
>
> I'm still lost about what to do. Grok is of no use to us at the
> moment. Many of these apps have been up and running for longer than
> Grok's been alive. Is there any kind of migration documentation out
> there? Or have these new ways of doing things been in use for so long
> that most people have just rolled along with them? I just don't have
> the time. I scarcely have time to keep up with the lists (which is
> obvious since I haven't read a thing for nearly three months).
>
> I'm going to resume my conversation here, responding to myself.
>
> August 16, 2007, Jeff Shell wrote:
> > > Jeff Shell wrote:
> > > > But now I'd like to be able to install that into "classic" zope 3.3
> > > > instance homes, trying
[Zope3-Users] Eggs and classic instance homes, again... (was Re: Eggs, workingenv.py, and 'classic' instance homes)
The last time I was active on this list was back in mid-august. I was fighting an uphill battle to try to figure out how to migrate our software to 'Eggs'. I ultimately had to abandon the process as there was just too much real work to be done, and I was getting conflicting answers about how to move forward. Actually, I couldn't get much help from the community at all. I apologize for the crankiness of this email. The last time I tried to get help on this topic was an excercise in sheer frustration. Since then, the gulf I've worried about seems to have gotten even bigger, and I'm feeling very stressed right now. So now I see all that's going on with Zope 3 and I still don't understand a thing about how to move forward. We have about twelve active customers deployed on Zope 3, on top of one or two large frameworks that we've built on top if Z3. We still use the basic 'instance home' layout. We don't use eggs - we just check things out directly into the instance home. Even stuff from the Zope community, because it's easier to do that than to even get workingenv or any of these other things running. I'm still lost about what to do. Grok is of no use to us at the moment. Many of these apps have been up and running for longer than Grok's been alive. Is there any kind of migration documentation out there? Or have these new ways of doing things been in use for so long that most people have just rolled along with them? I just don't have the time. I scarcely have time to keep up with the lists (which is obvious since I haven't read a thing for nearly three months). I'm going to resume my conversation here, responding to myself. August 16, 2007, Jeff Shell wrote: > > Jeff Shell wrote: > > > But now I'd like to be able to install that into "classic" zope 3.3 > > > instance homes, trying to be as unobtrusive as possible. > > > > How have you installed other packages before? I suspect by just dumping > > their source in INSTANCE/lib/python. Any reason not to continue to do that? > > Because I feel like we're falling further and further behind, or at > least trapped in our own little world. Yep, this is becoming even more true. We're now even further behind. > But yes, this is how we did it. I ended up writing most of > rocketbuild/rockout (our Rake-ish tool) because of this. There are a > lot of external tools out there that we still don't use because we > don't have the time to deal with the headache (made minor by > `rockout`, but still present) of dumping sources into lib/python. For > internal stuff, it's not so bad. I want to get away from this (using source control as distribution mechanism). Eggs and buildout are supposed to help here, but ultimately it was easier to roll our own tool as we just could not figure out how to apply them to our configurations. We're about to do a massive server upgrade, which would be a good time to sneak in new deployment practices. > The longer we avoid whatever is going on with setuptools and buildout, > the harder it will be to migrate. It's hard enough already. Yep. Feels even harder now, but probably because they cause me so much stress just by looking at them. > > That seems backward. If you want to install an package into a "classic" > > environment, it doesn't seem that surprising you'll also have to do it > > the "classic" way... > > It doesn't seem entirely backward. I mean, it does. But at the same > time... I just don't know how it's all supposed to work. But if we > keep doing things in the 'classic' way without trying to step forward, > then I fear we'll stay this way forever because it's already scary > enough peeking over the hill at how buildout and all of that stuff > works and how different it is from how we've done things. I don't want > the gulf to get bigger, because I think that with our plans for growth > and for a more distributed deployment server setup, 'buildout' will > help tremendously. > > I'm just trying for baby steps right now, because it feels like we've > still got a long way to go to get to anything better. > > I saw mention of 'workingenv' in your book, so I assumed it was or is > possible to easily have instance homes with locally managed eggs. > Shouldn't it be? Still have a long way to go. Still have no answers for what to do or how to start migrating. Some of our problem is caused by the stupidity of CVS, which will go away when we migrate to Git. Is there going to be a Zope 3.4, for real this time? Will it offer the clues I'm looking for? 'zopeproject' says 'You can start a new Zope-based web application from scratch with just two commands'. But what about those of us who have started many many Zope based web projects? Thanks, Jeff Shell ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: lack of security declaration: bug or feature?
Oh, I didn't know you could use the 'attributes' attribute in the require directive! It looks quite useful and fits perfectly in this case. Thanks for your answers to this newbie! Lorenzo El lun, 05-11-2007 a las 13:10 +0100, Thierry Florac escribió: > Le lundi 05 novembre 2007 à 12:35 +0100, Lorenzo Gil Sanchez a écrit : > > Oh, that's true indeed. It's a shame IOrderedContainer is defined as > > inheriting from IContainer because I can't declare a permission for the > > updateOrder method in an independent way. Something like: I want Public > > permission for reading an ordered folder and I want ManageContent > > permission for writing *and* changing the folder order. > > I've done this configuration, which seems OK for me until now : > > > interface="zope.annotation.interfaces.IAttributeAnnotatable" /> > interface="zope.app.container.interfaces.IReadContainer" > permission="zope.View" /> > interface="zope.app.container.interfaces.IWriteContainer" > attributes="updateOrder" > permission="zope.ManageContent" /> > > > > Thierry Florac ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Find the zope3 instance home directory (or the /var directory)
On Nov 6, 2007, at 5:02 AM, Eric Bréhault wrote: Hello, WIth Zope2, when I need to create or read a file in the filesystem, I usually go in /myzopeinstance/var directory and to find it is pretty easy: import os os.environ['CLIENT_HOME'] But in Zope3, CLIENT_HOME or INSTANCE_HOME are no longer provided in os.environ I had a look to different source code, and apparently the solution is to use the path of the current file to get the instance home, so we have code like this: os.path.normpath( os.path.join (os.path.dirname(__file__), os.pardir, os.pardir, os.pardir, os.pardir)) Is there any easier (and cleaner) way to do it ? Yes. If you want to have a directory like this: - Create it (or arrange for it to be created lazily) - Configure it in zope.conf: directory /location/of/directory - To get this information from Python: import zope.app.appsetup.product var_dir = zope.app.appsetup.product['var']['directory'] As has been pointed out, there is no equivalent of an instance home in Zope 3, because we don't want to impose such a restrictive model, but you can easily provide such a model for yourself if you wish. Jim -- Jim Fulton Zope Corporation ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Find the zope3 instance home directory (or the /var directory)
Stefan H. Holek wrote:
> I don't think there is any way whatsoever in Zope 3. There is no
> "instance" home to begin with, and the os.pardir hacks don't work
> either because you can't really know where your package is installed.
>
> Stefan
>
>
> On 6. Nov 2007, at 11:02, Eric Br�hault wrote:
>
>> I had a look to different source code, and apparently the solution is
>> to use
>> the path of the current file to get the instance home, so we have
>> code like
>> this:
>> os.path.normpath(
>> os.path.join(os.path.dirname(__file__),
>> os.pardir, os.pardir, os.pardir, os.pardir))
>>
>> Is there any easier (and cleaner) way to do it ?
>
I have found useful another trick related to __file__ .
If the file system location you are looking for is near code you are
using or can import, python's "inspect" may be your friend.
>>> import inspect
So, if your object is, for example, a view method and you need the
directory where another method is defined for your view, you can
>>> sourcefilepath = inspect.getsourcefile(self.otherMethod)
Here's another example for clarification. It works, but is not
particularly useful:
Let's say we want to know the file system location where
Decimal.normalize is defined.
>>> from inspect import getsourcefile
>>> from decimal import Decimal
We can get the location directly:
>>> getsourcefile(Decimal.normalize)
'/usr/lib64/python2.5/decimal.py'
Or, if we just want the location of the class:
>>> getsourcefile(Decimal)
'/usr/lib64/python2.5/decimal.py'
or, we can get the location from an instance:
>>> d = Decimal('0.12')
>>> getsourcefile(d.normalize)
'/usr/lib64/python2.5/decimal.py'
>From there, standard os.path functions can get you locations relative to
the location given.
HTH,
-Jim Washington
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Securitypolicy issues when moving to eggs
Hi Jesper, Am 06.11.2007 um 13:02 schrieb Jesper Petersen: Hi, I recently moved my webapp from z3.3.1 tarball to all eggs. It's working great except for my securitypolicy, which seems to sort of half-work. For example, earlier an authenticated member could view http://myhost/mysite/@@footest.html with and without the "@@" but now it's only viewable with them. Note that with the "@@" you traverse the view via the 'view' namespace traverser defined by the zope.traversing package, without them Zope uses the ItemTraverser defined by the zope.app.container package. Both traversers perform an adapter lookup for your view 'footest.html'. One possible reason for your problem might be that the security declarations for the traversers themselves differ. Regards, Markus Kemmerling___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
