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? _______________________________________________ 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