[Repoze-dev] Fwd: DRAFT: Invitation to a dance
Chris McDonough
chrism at plope.com
Sat Sep 29 12:11:53 UTC 2007
D'oh, continue forwarding this thread...
Begin forwarded message:
> From: Philipp von Weitershausen <philipp at weitershausen.de>
> Date: September 29, 2007 7:52:45 AM EDT
> To: Chris McDonough <chrism at plope.com>
> Cc: Christian Theune <ct at gocept.com>, Martijn Faassen
> <faassen at startifact.com>, Jim Fulton <jim at zope.com>, Ian Bicking
> <ianb at colorstudy.com>, "Phillip J. Eby" <pje at telecommunity.com>,
> Rob Miller <ra at burningman.com>, Joel Burton <joel at joelburton.com>,
> Martin Aspeli <optilude at gmx.net>, Graham Dumpleton
> <graham.dumpleton at gmail.com>
> Subject: Re: DRAFT: Invitation to a dance
>
> On 29 Sep 2007, at 01:21 , Chris McDonough wrote:
>> On Sep 28, 2007, at 5:04 PM, Philipp von Weitershausen wrote:
>>
>>> My talk at PloneConf revolves around Plone's exit strategies into
>>> a Zope3/WSGI/Paste/... world. Can I mention repozo? I'd hate to
>>> steal your thunder, so I'll be happy to keep quiet about it. But
>>> it seems like such a perfect fit.
>>
>> I think that'd be great. Paul was also toying with the idea.
>
> So that sounds like you don't object? Because my talk is exactly
> about how Plone should embrace The WSGI+Stack from the bottom pu.
>
>>> I actually had the same idea, but I went further and tried using
>>> zope.publisher. That has several advantages, because
>>> zope.publisher is already WSGI-aware and quite pluggable. I got
>>> reasonably far, in such that I could render the ZMI (but without
>>> security). My work is here: http://svn.zope.org/Sandbox/philikon/
>>> five.publication/. It's a buildout and should therefore be
>>> reproducible for anyone who wants to try out.
>>
>> Yup, looks familiar. ;-) We had a 22nd-level goal (not very
>> important at all, IOW) of letting people create "obob" plugins
>> without needing to know anything about the Zope component
>> architecture, so that's why it's the way it is currently.
>
> Yes, and that approach has some appeal to it. I shall look more
> into "obob"... Seriously, guys, you couldn't have picked a better
> name? :)
>
>>> The buildout fetches Zope 2 completely via eggs, by the way.
>>> They're available on download.zope.org. I haven't bothered making
>>> them "official" on the CheeseShop yet. Perhaps they could make
>>> the 'zopelib' tarball obsolete in the future?
>>
>> Can you point me at a URL for the package(s)? We'd love to be
>> able to get out of that business. ;-)
>
> I basically split Zope 2.11 into
>
> * Zope 3.4.x from eggs,
>
> * the ZODB3 from egg,
>
> * reusable packages that are maintained within the 'Zope' tree, but
> could just as well be maintained outside:
>
> - Acquisition
> - DateTime
> - ExtensionClass
> - Interface
> - Persistence
> - zLOG
>
> Each of those are managed as individual projects on svn.zope.org,
> just like all other packages. Their 'src' directory has an external
> to the Zope 2 trunk. For now I made those awful continuous dev
> releases just to toy around. The real value is in the package
> metadata. I think in the long term, we should move those packages
> out of the 'Zope' tree. Most of them are just for legacy anyway.
>
> * the rest which is in a big 'Zope2' egg: http://svn.zope.org/
> Zope2.buildout
>
> The packages are managed in svn.zope.org, just like any other
> package there. Their 'src' directory has an external to the Zope 2
> trunk.
>
> The eggs can be found at http://download.zope.org/distribution/
>
>
>>> You say you have work planned for Zope3 and Grok. I'm quite
>>> surprised that there's so much to do here. If you look at
>>> zopeproject's generated code, you'll see that Zope 3 is pretty
>>> much there already for Paste deployment. Perhaps it could use a
>>> bit more integration into repozo, I suppose.
>>
>> That's good. I'm not sure there's much to do there, because the
>> installers for repoze.zope2 and repoze.plone are just for
>> convenience, they aren't meant to represent any sort of suggestion
>> or competition to any "real" build system. So really it would
>> just be somebody getting a sandbox up and going and *maybe* trying
>> to change the publisher to reuse some of the middleware we've made
>> (repoze.tm, repoze.vhm {which still needs Zope3 support}).
>
> Right. I suppose it's just a matter of testing those middlewares
> with Zope 3.
>
>>> I took a closer look at your zope.server integration. A lot of
>>> the code you have is already in zope.server. I recently made sure
>>> it has all the necessary WSGI variables (that was a bugfix to the
>>> 3.4.x line) and then I added a PasteDeploy-style entry point
>>> (that's a feature, so it's in the 3.5.x line). Just so you know...
>>
>> Thanks. We were developing against a baseline of Zope 2.10.4, so
>> once we have a Zope 2 that has this stuff in it, we can get rid of
>> the server.
>
> ... or once you use Zope 2 from eggs...
>
>>> I'm more skeptical about things like transactions, but I suppose
>>> it would make it easier for non-Zope applications.
>>
>> There's a bit of precedent for this sort of thing.
>>
>> http://www.djangoproject.com/documentation/transactions/
>>
>> http://pythonpaste.org/module-paste.transaction.html
>>
>> But yes, this is more a feature that makes it possible to use the
>> 'transaction' module in non-Zope applications a bit more easily.
>
> It certainly helps making non-Zope applications that don't use any
> form of publisher transaction-aware. It just needs to be integrated
> well with aborting and/or dooming transactions upon errors.
>
>>> I'm quite impressed by the mod_wsgi integration. I need to try
>>> this again. How does it deal multithreadedness and interpreter
>>> boostrap?
>>
>> This story is not nearly as cooked as the "development sandbox" or
>> "pure python server" story. There's still a lot of figuring out
>> to do here. I played around and found that mod_wsgi can be
>> configured to run programs in a mode a lot like fastcgi, where it
>> starts up processes that don't live "inside" Apache;
>
> That's great news. I didn't know about this.
>
>> you can sort of turn knobs up and down for number-of-threads and
>> number-of-processes for each one of these (I must admit I don't
>> quite understand the number-of-threads parameter yet), as well as
>> which user the process should be started as (which is very
>> handy). For http://www.repoze.org/tmp/plone, the configuration is:
>>
>> WSGIPythonExecutable /home/repoze/tmp/site/bin/python
>> WSGIDaemonProcess tmp threads=1 processes=4 maximum-requests=10000
>>
>> <Directory /home/repoze/tmp/site/etc>
>> Order deny,allow
>> Allow from all
>> </Directory>
>>
>> <VirtualHost *:80>
>> DocumentRoot /home/repoze/www/www.repoze.org
>> ServerName www.repoze.org
>> ScriptAlias /viewcvs "/usr/lib/cgi-bin/viewcvs.cgi"
>> ServerAdmin repoze-dev at repoze.org
>> WSGIScriptAlias /tmp /home/repoze/tmp/site/etc/zope2.wsgi
>> WSGIProcessGroup tmp
>> WSGIPassAuthorization On
>> SetEnv HTTP_X_VHM_HOST http://www.repoze.org/tmp
>> </VirtualHost>
>>
>> In any case, it does run, but we don't have much information on
>> stability nor do we have a truly well-understood configuration
>> yet. It's a bit of a limitation that you can't specify a
>> WSGIPythonExecutable per virtual-host (and thus not need to do any
>> PYTHONPATH or sys.path munging), and because the Paste pipeline
>> doesn't seem to be created until the first request, it can take a
>> while for the site to "settle down" once it comes up (it might
>> take 30 seconds to render a single image at first startup time,
>> because it's boostrapping a process).
>
> I've just tried to do this with a zopeproject-based application but
> I couldn't get very far. mod_wsgi would ignore my
> WSGIPythonExecutable setting, no matter where I pointed it to. I'll
> keep trying, though.
>
_______________________________________________
Repoze-dev mailing list
Repoze-dev at lists.repoze.org
http://lists.repoze.org/mailman/listinfo/repoze-dev
More information about the Repoze-dev
mailing list