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