All,
Windows
=======
Sidnei, et al.: your points are well-taken and your expertise
appreciated. Thanks!
pywebd
======
Bob: I'm on board with your vision for a common server library
here. Count me in.
webctl/filesystem layout/config syntax
======================================
This is looking less hopeful as a place to collaborate:
- An executable needs a config file on the command line, and/or
a config file in a pre-determined place.
- *Requiring* a config file on the command line is butt-ugly.
- Our opinions regarding filesystem layout seem to be, um,
non-overlapping.
I'd like to venture one more round on this, however, before
giving up on it:
- It might be the case that Zope only has a few files in an
INSTANCE_HOME, but I find myself putting quite a bit in a
site's userland:
- I'll install Python packages in there wholesale, so I get
their scripts in bin/, and lots of modules in lib/python.
- I have multiple configuration files in etc/ (as
discussed) along with templates in etc/templates/.
- I put documentation in doc/.
- I have site-specific utility or cron scripts in bin/.
- I have extra data files in var/.
Keeping it all in svn means that a website is very nearly
self-contained and isolated, requiring not much besides
Python to be installed in the base system. This is great for
many-sites-on-one-server.
- For one-site-on-many-servers, why does a Unix-y userland for
development conflict with deployment? That is, why can't a
development userland simply be installed into /usr/local for
deployment? Surely logging differences could be handled in
configuration, no?
- Besides, my proposal only specified two requirements:
etc/<foo>.conf
lib/python
Is there really a Unix sysadmin that would balk at this? This
is all that's really needed for a common executable to get
your site online. Lay out the rest however you want.
- Jim, you hold particular distain for lib/python, but it's
probably the best example of my "standards enable tools to
evolve" argument: lib/python buys you distutils, setuptools,
easy_install, workingenv, etc.
- This same principle makes sense of runzope, scriptzope, and
debugzope: standardize the file format (= fs layout), and
such tools fit perfectly in /usr/local/bin.
- Almost all of the Windows discussion has centered on daemons
vs. services. Sidnei, et al.: what does a "native" Windows
filesystem layout look like for a web application? Is using a
self-contained Unix-inspired layout faux pas?
- As mentioned wrt PHP, users like familiar filesystem layouts.
Reaching agreement here improves our story for newcomers.
A common executable (= common fs layout) may very well be pushing
the limits of collaboration too far, but I'll feel better about
admitting that if we pursue the conversation a bit further.
chad
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
