-----Original Message----- From: Ted Skolnick [mailto:ted.skolnick@reis.com] Sent: Tuesday, April 23, 2002 11:40 AM To: 'Oliver Bleutgen' Subject: RE: [Zope] Re: [Zope-dev] Separate staging and development areas for a product Hi, Ted here. I started this thread a while back, and came up with a solution that works for me. I hope it is helpful for others too. If u find a flaw in it, please let me know. Goal: To run both a dev and staging environment on one Zope. This must work with external methods, and modules imported by those external methods (i.e. file based products). In other words, I will have files with the same name on the system in different directories. What I did: 1) Created my dev project The external methods reside in /usr/zope/lib/python/Products/dev/Extensions Python files that r imported by those external method modules also reside in that same directory (or a package within there). 2) Made a copy of dev, both in Zope and on file system, called it staging. Now all the same files exist in /usr/zope/lib/python/Products/staging/Extensions as well. (don't forget ur __init__.py files in all dirs!) 3) Update the external method path's in the Zope mgmt. interface. Lets say I had an external method module called myfuncs.py . In dev the external module path is dev.myfuncs, while in staging I need to make it staging.myfuns. So, there is no code changes between dev and staging. The only changes r in the zope mgmt interface for hooking up the external method paths. 4) The interesting part: If u just do the above, it will not work. The reason is that external methods use the ExternalMethod product, which in turn uses Extensions.py. When u invoke an external method, it is loaded with an exec command from within Extensions.py. As a result, it is loaded within the context of Extensions.py and can not import other modules from the directory that actually contains ur external method. At first I fixed this by adding to my python path. But if u do that, u can only import either dev or staging files, whichever comes first in the python path. So.... I hacked Extensions.py with a very small change. Instead of allowing Extensions.py to do an exec, I made it do an import to load the module so that my dev and staging modules will be loaded from the context of their own directories, and will therefore import modules from their own directory. In this way dev external methods import modules from the Products/dev/Extensions directory, and staging will import from Products/staging/Extensions/. The hack could be more robust, but it is very short, and is getting me back on the road to staging... code excerpt from Extensions.py..... Starting at line 140: else: try: execsrc=open(p) except: raise "Module Error", ( "The specified module, <em>%s</em>, couldn't be opened." % module) #m={} <<<<<<<<<<<<<< Commented out the old way of loading module #exec execsrc in m <<<<<<<<<<<<<< Commented out the old way of loading module # >>>> Start of my new stuff modNameParts = split( module, "." ) module = "Products." + modNameParts[0] + ".Extensions." + modNameParts[1] exec ( "import " + module + " as m" ) # >>>> End of my new stuff funcToRetrieve = "m." + name try: r= eval( funcToRetrieve ) #<<<<<<< I replaced this line too.. usde to say r = m[name] -Ted -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Oliver Bleutgen Sent: Tuesday, April 23, 2002 5:12 AM To: John Schinnerer Cc: zope@zope.org Subject: Re: [Zope] Re: [Zope-dev] Separate staging and development areas for a product John Schinnerer wrote:

Aloha,

<snip>...

...

... but I really need my development version accessible to the internet, too. And it would be nice to have three versions so I could have a separate testing version public, as well.

...

What should someone like me do in order to develop a product that is also in use on my server? What do other independent developers do?

Zope 'version' objects (Ch. 3, zope book, near the end) supposedly address some of your issues (which are similar to some of mine - I too would like to have fully functional preview/test sites available on my live server). I haven't tried versions yet, though, because...

What the zope book info on versions doesn't say (and I haven't found elsewhere either) is how (or if it's even possible) to access a version

...

from outside the management interface - that is, as a client would see it in their browser, so it can be tested before changes are committed to the 'public' version. If I can't do that, and do it transparently, versions don't do me any good. There'd have to be some URL trickery somewhere to serve up a version without breaking buckets 'o links...

When you enter a version, you just get a cookie named 'Zope-Version' with the path to your version as a value. You can see it for yourself if you configure the browser to ask before accepting cookies and look at the cookie details. In Zope 2.3.3, and I suspect in any zope after that also, it's possible to just set this cookie, and the browser is in that version. Therefore the permission 'join/leave versions' is quite useless IMO. The upside is that you need just a short code snippet (setting that cookie) to let anyone (including anonymous) enter any version. Downsides are obvious and manyfold. cheers, oliver _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )