[Web-SIG] A Python Web Application Package and Format
Alex Grönholm
alex.gronholm at nextday.fi
Mon Apr 11 22:49:20 CEST 2011
11.04.2011 22:48, Alice Bevan–McGregor kirjoitti:
> On 2011-04-11 00:53:02 -0700, Eric Larson said:
>
>> Hi,
>> On Apr 10, 2011, at 10:29 PM, Alice Bevan–McGregor wrote:
>>
>>> However, the package format I describe in that gist does include the
>>> source for the dependencies as "snapshotted" during bundling. If
>>> your application is working in development, after snapshotting it
>>> /will/ work on sandbox or production deployments.
>>
>> I wanted to chime in on this one aspect b/c I think the concept is
>> somewhat flawed. If your application is working in development and
>> "snapshot" the dependencies that is no guarantee that things will
>> work in production. The only way to say that snapshot or bundle is
>> guaranteed to work is if you snapshot the entire system and make it
>> available as a production system.
>
> `pwaf bundle` bundles the source tarballs, effectively, of your
> application and dependencies into a single file. Not unlike a certain
> feature of pip.
>
> And… wait, am I the only one who uses built-from-snapshot virtual
> servers for sandbox and production deployment? I can't be the only
> one who likes things to work as expected.
>
>> Using a real world example, say you develop your application on OS X
>> and you deploy on Ubuntu 8.04 LTS. Right away you are dealing with
>> two different operating systems with entirely different system calls.
>> If you use something like lxml and simplejson, you have no choice but
>> to repackage or install from source on the production server.
>
> Installing from source is what I was suggesting. Also, Ubuntu on a
> server? All your `linux single` (root) are belong to me. ;^P
I use Ubuntu on all my servers, and "linux single" does not work with
it, I can tell you ;P
>
>> While it is fair to say that generally you could avoid packages that
>> don't use C, both lxml and simplejson are rather obvious choices for
>> web development.
>
> Except that json is built-in in 2.6 (admittedly with fewer features,
> but I've never needed the extras) and there are alternate xml parsers,
> too.
>
>> It sounds like Ian doesn't want to have any build steps which I think
>> is a bad mantra. A build step lets you prepare things for deployment.
>> A deployment package is different than a development package and
>> mixing the two by forcing builds on the server or seems like asking
>> for trouble.
>
> I'm having difficulty following this statement: build steps good,
> building on server bad? So I take it you know the exact target
> architecture and have cross-compilers installed in your development
> environment? That's not practical (or simple) at all!
>
>> I'm not saying this is what you (Alice) are suggesting, but rather
>> pointing out that as a model, depending on virtualenv + pip's
>> bundling capabilities seems slightly flawed.
>
> Virtualenv (or something utilizing a similar Python path 'chrooting'
> capability) and pip using the extracted "deps" as the source for
> "offline" installation actually seems quite reasonable to me. The
> benefit of a known set of working packages (i.e. specific version
> numbers, tested in development) and the ability to compile C
> extensions in-place. (Because sure as hell you can't reliably compile
> them before-hand if they have any form of system library dependency!)
>
>> I think it should offer hooks for running tests, learning basic
>> status and allow simple configuration for typical sysadmin needs
>> (logging via syslog, process management, nagios checks, etc.).
>> Instead of focusing on what format that should take in terms of
>> packages, it seems more effective to spend time defining a standard
>> means of managing WSGI apps and piggyback or plain old copy some
>> format like RPMs or dpkg.
>
> RPMs are terrible, dpkg is terrible. Binary package distribution, in
> general, is terrible. I got the distinct impression at PyCon that
> binary distributable .eggs were thought of as terrible and should be
> phased out.
>
> Also, nobody so far seems to have noticed the centralized logging
> management or deamon management lines from my notes.
>
>> Just my .02. Again, I haven't offered code, so feel free to ignore
>> me. But I do hope that if there are others that suspect this model of
>> putting source on the server is a problem pipe up. If I were to add a
>> requirement it would be that Python web applications help system
>> administrators become more effective. That means finding consistent
>> ways of deploying apps that plays well with other languages /
>> platforms. After all, keeping a C compiler on a public server is
>> rarely a good idea.
>
> If you could demonstrate a fool-proof way to install packages with
> system library dependencies using cross-compilation from a remote
> machine, I'm all ears. ;)
>
> — Alice.
>
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi
More information about the Web-SIG
mailing list