[Web-SIG] more comments on Paste Deploy
Phillip J. Eby
pje at telecommunity.com
Mon Mar 5 22:38:51 CET 2007
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.
In truth, it doesn't matter if the file *contents* are
standardized. Standardization could be as simple as defining a #! line like:
#!/usr/bin/pydeploy2.3 SomeFormatEgg==1.1
Where "SomeFormatEgg" offers a "python.deploy" entry point for running the
file, and the pydeploy tool obtains the necessary egg and provides
libraries for the parsing tool to auto-locate and install any eggs needed
by the body.
This could also be a basis for bootstrapping other systems, including
perhaps buildouts (e.g. "#!/usr/bin/pydeploy2.4 zc.buildout" at the top of
a buildout .ini)!
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?
More information about the Web-SIG
mailing list