[Web-SIG] A Python Web Application Package and Format

Alice Bevan–McGregor alice at gothcandy.com
Tue Apr 12 01:23:48 CEST 2011


Howdy!

On 2011-04-11 15:22:11 -0700, Ian Bicking said:

> I... think we are misunderstanding each other or something.

Something.  ;)

> A nice tool that could use this format, for instance, would be a tool 
> that takes an app and creates a puppet recipe to setup a sever to host 
> the application.  A different tool (maybe better, maybe not?) would be 
> a puppet plugin (if that's the terminology) that uses this format to 
> tell puppet about all the requirements an application has, perhaps 
> translating some notions to puppet-native concepts, or adding 
> high-level recipes that setup an appropriate container (which can be as 
> simple as a properly configured Nginx or Apache server).

Minuteman (loved the hat from the PyCon lightning talk), buildout, 
puppet, make, bash, custom XML-RPC APIs, … there are quite a number of 
ways to push something into production.  Standardizing on one would 
marginalize the idea, and being agnostic means there is a whole /lot/ 
of work to be done to add support to every tool.  :/

> What I mean when I say there's a danger of becoming a configuration 
> management tool, is that if you include hooks for the application to 
> configure its environment you are probably stepping on the toes of 
> whatever other tool you might use.  And once you start down that path 
> things tend to cascade.

Have a gander at the Application Spec section; what, specifically, are 
you at odds with as coming from the application?  I work with 
specifics, not vague "don't do that!" comments.

The configuration of environment extends to:

:: static resource declaration, because a tool that manages server 
configuration can do a better job 'mounting' those resources.

:: services (in your parlance, 'resources' in mine) such as "give me an 
sql database".

:: recurrent tasks (a la cron) because having that centralized across 
multiple applications Isn't Just a Good Idea™ -- treat this as a 
'service' if you must.

> If you include something in the packaging format that indicates the 
> libraries to be installed, then you are encouraging and perhaps 
> requiring that the server install libraries during a deployment.

Libraries that are __bundled with the application__.  I fail to see the 
'badness' of this, or, really, how this differs from Silver Lining.

I'd double-check this, but cloudsilverlining.org is inaccessible from 
my current location for some reason.  :/

> Realistically this can't be entirely avoided, but I think it is a 
> pretty workable separation to declare only those dependencies that 
> can't reasonably be included directly in the application itself (e.g., 
> lxml, MySQLdb, git, and so on).  In Silver Lining those dependencies 
> were expressed as Debian package names, installed via dpkg, but for a 
> more general system it would need to be somewhat more abstract.

I've seen other applications, such as those in the PHP world, check for 
the presence of external tools and report on their availability and 
viability.  Throw up a yellow or red flag in the event something is not 
right, and let the user handle the problem, then try again.

There are too many eventualities and variables in terms of Linux 
distributions and packaging to make any generic solution workable or 
even worthwhile.  At least, until we have high-order AI replacing 
sysadmins.

> OK; then #4 is is the only thing I would choose to support, as it is 
> the most general and easiest for tools to support, and least likely to 
> lead to different behavior with different tools.  And not to just defer 
> to authority, but having written a half dozen tools in this area, not 
> all of them successful, I feel strongly that including dependencies is 
> best -- simplest for both producer and consumer, and most reliable.

Thank you for reading what I wrote.

	— Alice.




More information about the Web-SIG mailing list