[Zope3-dev] RFC: zopeproject

[Philipp von Weitershausen]

On 18 Jul 2007, at 22:34 , Maciej Wisniowski wrote:
>> I will add this to the zopeproject docs. I wonder:
>>
>> * Would it help if the 'myzopeapp' package would not be in the top- 
>> level MyZopeApp directory, but in a 'src' directory below  
>> MyZopeApp? Would that make it clearer where to go?
>>
>> * grokproject actually also creates a "hello world" browser page.  
>> That way there's some initial code there and people might know  
>> better where to go in and change stuff. Would that help? Or would  
>> that be too much unnecessary boilerplate?
> For me, second approach is more clear but even simple README.txt,
> located at new project's folder, with description of next steps,  
> should be enough.

The problem with boilerplate README files is that they're never  
changes after the fact, therefore making it look like your code has  
documentation while in fact it's just the unchanged boilerplate. At  
least the code *has* to be changed to make something useful out of it.

>>> 2. Is this kind of setup (I mean using zopeproject) supposed to be
>>> used to deploy applications in production environments?
>>
>> It certainly can be used for deployment, though you'll probably  
>> want to make some changes to the configuration files before you  
>> deploy (rip out the administrator account, deactivate developer  
>> mode, etc.). Again, this is a good question that should be  
>> answered in the zopeproject docs.
> Would be nice to have this kind of description, especially
> that a lot of people is not familiar with Paste (I think so). For
> example I was looking for something like zopectl start|stop|restart. I
> don't know so far how to do it (I did not read Paste docs yet - do I
> really have to? ;) ).

You shouldn't have to read docs on Paste just to get started. If you  
want to actually make use of it (e.g. middlewares via PasteDeploy), I  
suggest you do read up on it.

> One more thing that is rather about 'death to zope instances' not
> zopeproject itself is that that so far it was possible and easy to  
> have one Zope serving few different apps. With new way seems that  
> instance is bound to application.
> This may be a pain if you have to pay for hosting. Usually there are
> serious restrictions to number of long running processes (like  
> Zope) you may have (e.g. Webfaction hosting).

Aha. How stupid. I'm inclined to suggest to switch to a decent  
hosting provider :). A virtual server with root access is cheap these  
days.

Then again, WSGI will hopefully give us the possibility to serve Zope  
from within Apache, for example, therefore reducing the Zope's  
requirements for deployment. I think this model has fitted the  
scripters very well, probably one of the reasons why Perl and PHP are  
so successful.

Anyway, I have no short-term interest in supporting multiple Zope  
applications within the same "instance". Zope 3 was never really  
designed to work that way, anyway, because of all the global state  
that ZCML defines. (Unfortunately, that global state also makes it  
impossible to use two different Zope WSGI applications in the same  
Python process...)