FW: [Zope] Re: [Zope-dev] Separate staging and development areas for a product

Ted Skolnick ted.skolnick@reis.com
Tue, 23 Apr 2002 11:40:38 -0400 

-----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 )