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