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

[Ian Bicking]

(I'm confused; I just noticed there's a web-sig at python.org and
python-web-sig at googlegroups.com?)

On Mon, Apr 11, 2011 at 2:01 PM, Daniel Holth <dholth at gmail.com> wrote:

> 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/


Yes, this is all very reminiscent of my thoughts about this application
format, and I'm assuming web.xml is the kind of configuration file I expect,
etc.  I'd rather there be a convention like classes/ anyway (obviously with
a different name ;)


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

Yes; and for instance Silver Lining can have multiple versions installed
alongside each other, which makes it easier to do a quick update -- you can
upload everything, make sure everything is okay, and only then actually make
that new version active.  If the build process is well defined you can do
the same thing, but it's harder to be sure that it will work as expected.
 And if the build process is kind of free-form then you might end up in a
place where you have to take down the old version of an app as you update
the new version.

Data migrations are a bit more tricky, but with the services concept they
are possible, and can even be efficient if you use some deep Linux magic
(but if you are okay with a bit of inefficiency, or only applying this to
small databases, doing a fairly atomic application update is possible).

One of the items in Silver Lining's TODO is having a formal concept of
putting an application into read-only mode, which could be helpful for these
updates as well.

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

PYTHONPATH shouldn't apply here, as it informs the Python executable, and
probably the executable will start before invoking the application (at least
with mod_wsgi it does, and there's a lot of other use cases where it could).
 You could have a setting in app.ini (or whatever equivalent config file)
with the paths to add, but I personally find that kind of messy feeling
compared to existing conventions like .pth files.  Ultimately they are
equivalent -- a file with a path name that is added to sys.path.

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
>

That's kind of a red herring -- even if setup.py goes away it would be
replaced with something (pysetup I think?) which is conceptually equivalent.

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