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

[Daniel Holth]

We have more than 3 implementations of this idea, the Python Web Application 
Package and Format or WAPAF, including Java's WAR files, Google App Engine, 
silverlining. Let's review the WAR file, approximately:

(static files, .jsp)
WEB-INF/web.xml
WEB-INF/classes/org/example/myapplication.class
WEB-INF/lib/some-library.jar
WEB-INF/lib/145-other-libraries.jar

Build the .war file, copy to server, done (ideally). Your program should 
require a standard Java installation plus whatever's in the .war file. The 
.war file is a .zip that follows certain conventions.

In practice you might develop in and deploy exploded .war files which are 
exactly the same thing but unzipped.

Since it's Java there is no classes/SQLAlchemy/src/sqlalchemy/__init__.py; 
the path for the code always starts at classes/, not at some arbitrary set 
of subdirectories under classes/

> installation.  Better to have an application rejected up-front ("Hey, 
> this needs my social insurance number? Hells no!") then after it's 
> already been extracted and potentially littered the landscape with its 
> children.
>
Part of the potential win here is that the application need not litter 
anything. Like GAE, the server might keep all the previous versions you've 
uploaded and let you pick which one you want today. You shouldn't have to 
think about the state the server.

> > My model does not use setup.py as the basis for the process (you could 
> > build a tool that uses setup.py, but it would be more a development 
> > methodology than a part of the packaging).
>
> I know.  And the end result is you may have to massage .pth files 
> yourself.  If a tool requires you to, at any point during "normal 
> operation", hand modify internal files… that tool has failed at its 
> job.  One does not go mucking about in your Git repo's .git/ folder, as 
> an example.
>
If I read the silverlining documentation correctly the .pth is created 
manually in the example only because there was no 'setup.py' to 'pip install 
-e'. As an alternative the spec could only add particular directories to 
PYTHONPATH. This might be a distutils2 thing.

> How do you build a release and upload it to PyPi?  Upload docs to 
> packages.python.org?  setup.py commands.  It's a convienent hook with 
> access to metadata in a convienent way that would make an excellent 
> "let's make a release!" type of command.
>
setup.py should go away. The distutils2 talk from pycon 2011 explains. 
http://blip.tv/file/4880990

> It might be just me (and the other people who seem to enjoy WebCore and 
> Marrow) but it is fully possible to do install-time dependencies in 
> such a way as things won't break accidentally.  Also, you missed 
> Application Spec #4.
>
It is important that the WAPAF work with RSYNC. Just move the install-time 
dependencies part into the 'building the WAPAF' stage of the process and we 
are on the same page. This supports e.g. the 'server notices application is 
popular, spins up a new instance, and uses RSYNC to deploy the application 
onto the new server' use case, or perhaps 'the server isn't running at all, 
but you can deploy, and it will get around to starting your application when 
it is turned on'.

> > if you have a build process there is a significant chance that the two 
> won't match.
>
> I have never, in my life, encountered that particular problem.
>
It does exist.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20110411/958e2b54/attachment.html>