Re: directory layout and deployment best practice

On Fri, Aug 19, 2005 at 07:01:53PM +0200, Charl P. Botha wrote:
> Dear list,

> What is considered to be best practice with regards to the directory
> layout and deployment of SkunkWeb applications?  For example, should I
> just integrate my application code / components with the global
> docroot?  What am I supposed to do with python modules and packages
> required by my skunkweb components, i.e. where exactly should this go
> (I obviously don't want this kind of library code hanging around in
> the docroot)?  If these library modules go somewhere else, what's a
> consistent way to adapt the sys.path in all my skunkweb components?
>
> I think my main question is: how do I keep my own code and the
> SkunkWeb installation directory separate?  I would prefer not to have
> to copy my own modules to the pylibs directory for instance, as this
> would complicate upgrades and the like.

Components do need to be in the docroot (or in a skunkweb product,
which amounts to the same thing).  Modules should not be; they should
be in a separate "sitelibs" directory that you can add to sys.path in
sw.conf.  

No particular organizational strategy in the docroot is enforced,
obviously; you need to come up with your own convention (or maybe
other folks will share theirs).  If you want to divide up components
in directories according to their role in a pattern -- models/,
controllers/, etc. -- go ahead.  My personal practice in this regard
is nothing to write home about -- lots of "comp" subdirectories with
semi-private stuff tucked in them -- so I'll shut up about it.

If you use a vfs.MultiFS as the document root vfs
(Configuration.documentRootFS), then you can also arrange your
document root is peculiar ways, mounting different directories in
different places.  You can even use "sliding" mounts that stay in the
same place regardless of what the document root is.  This, combined
with scoping the document root (don't forget to cache the cache roots
when you do this), gives you a lot of flexibility.

The product service offers another organizational and deployment
strategy.  I don't know if it is used much, but you can use it to
package a mixture of sitelibs and components in a zip file.  A
discussion of it may be found here:

  http://www.smullyan.org/smulloni/approx_py/article2.html#the-product-service

Cheers,

js


-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDBhUluqamFyFXXLIRAnixAJ9Aot7JyEdlrygO/R6X7L0YZgeRfgCeLR3X
9WoC6mtLf1HFFCW7mbEcnv0=
=zRkY
-----END PGP SIGNATURE-----