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

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to