[Web-SIG] more comments on Paste Deploy

[Joseph Tate]

On Monday 05 March 2007 16:38:51 Phillip J. Eby wrote:
> At 10:02 AM 3/5/2007 -0500, Jim Fulton wrote:
> >Entry points add *a* mechanism to make those objects a bit more
> >discoverable.  Arguably, specifying an application via:
> >eggname#entrypointname doesn't provide much advantage over simply
> >specifying the dotted path to an object in a module.
>
> Actually, it provides one very important strategic advantage that I don't
> think has been mentioned in this conversation.  A configuration format that
> can specify project/version information can be used as a single-file
> deployment spec for an easy_install wrapper or buildout-like tool.
>
> The advantage of this for virtual hosting providers in particular is
> significant -- if they support the tool, they can support this one-file
> deployment scheme.
>
> Personally, I don't care for the Paste Deploy syntax -- frankly it's almost
> barbaric.  :)  But the concept of being able to specify stacks, routes, and
> configuration in a plain text format that includes package information for
> automated deployment is nonetheless an important one.
>
> A couple years back, I started writing a library to parse a more
> sophisticated, Python-like syntax to do the same sorts of things, but only
> got as far as the parser.
>
> One discussion was here:
>
> http://mail.python.org/pipermail/web-sig/2005-August/001714.html
>
> The basic idea behind the syntax was that assignments are like keyword
> arguments, and non-assignment statements are positional arguments.
>
> I'm not altogether happy with that syntax either, however, as it has a
> little too much "more than one way to do it", which is one reason I never
> finished the implementation.  There is a library that parses it (and does
> other general-purpose Python-like DSL parsing) at:
>
> ViewSVN:   http://svn.eby-sarna.com/SCALE/
> Checkout:  svn://svn.eby-sarna.com/svnroot/SCALE/
> Docs:
> http://peak.telecommunity.com/DevCenter/scale.dsl#parsing-declarations
>
> Anyway, all that aside, I think it would be fantastic if we could come up
> with some "universal file format" for single-file configuration and
> deployment of applications (including auto-install of all needed eggs),
> that could get stdlib support and ultimately hosting company support.  This
> would actually give us a leg up on even PHP for ease-of-deployment.

Doesn't setuptools already give this?  easy_install foo.app.egg will install 
all of the needed eggs if the dependencies are properly listed.

> So, while a single content format would be nice, we don't even need that in
> order to get a raw deployment system standard.  Perhaps I should build this
> hypothetical pydeploy tool into setuptools 0.7?

I don't see there being a lot of demand for this.  The use case I'm 
considering is the end user developer or administrator deploying one or more 
delivered pyhon web applications to a production environment (self hosted, 
colo-hosted, or leased server).  I think that except for where you have 
multiple servers behind a load balancer or something, this is a one time 
operation (barring failure cases, etc).  Administrators already script this 
kind of thing using shell.

Also, in any "enterprise" environment that I'm familiar with, the 
automatically download and install software mechanism wouldn't fly.   
Administrators want to know everything that goes on a system, and want the 
software managed through their patch/package management system.  
Philosophical discussions on whether that's good or not seem to be 
irrelevant.

Those using $4.95 hosting plans are only setting up one server, and will need 
something custom to their installation anyway, so "pydeploy" won't help them 
either.  They'll be trying to install trac, some blogging software and then 
an arbitrary image gallery, et. al., but won't have the same selections as 
another $4.95 hosting customer.  This is the key problem we're trying to 
solve.

I consider the packaging and delivery problem solved[1], or at least out of 
the scope of this problem.

-- 
Joseph Tate
Software Engineer
rPath Inc.
http://www.rpath.com/rbuilder/
(919) 851-3984 x2106

[1] Good enough for most things but better support for stuff outside the egg 
is needed: config files (so that the user can tweak them), locale data 
(or maybe a pkg_resources wrapper for gettext that loads that data from the 
egg).