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

[Ian Bicking]

On Mon, Apr 11, 2011 at 2:56 AM, Ionel Maries Cristian
<ionel.mc at gmail.com>wrote:

> Hello,
>
> I have few comments:
>
>    - That file layout basically forces you to have your development
>    environment as close to the production environment. This is especially
>    visible if you're relying on python c extensions. Since you don't want to
>    have the same environment constraints as appengine it should be more
>    flexible in this regard and offer a way to generate the project dependencies
>    somewhere else than the depeloper's machine.
>
> Yes; in this case in Silver Lining I have allowed non-portable libraries to
be declared as dependencies, and then the deployment tool ensures they are
installed.


>
>    - There's no builtin support for logging configuration.
>
> This would be useful, yes; though I think the format itself would mostly
want to declare how it logs and then deployment tools could try to configure
that.  E.g., it would be useful to have a list of logging names that an app
uses.  The actual configuration is deployment-specific, so shouldn't be
inside the application format itself.


>
>    - The update_fetch feels like a hack as it's not extensible to do
>    lifecycle (hooks for shutdown, start, etc). Also, it's shouldn't be a
>    application url because you'd want to run a hook before starting it or after
>    stopping it. I guess you could accomplish that with a wsgi wrapper but there
>    should be a clear separation between the app and hooks that manage the app.
>
> In Silver Lining you can also do scripts; I started with URLs because it
was simpler on the implementation side, but scripts have generally been
easier to develop, so at least the default could be revisited.

At least in the case of mod_wsgi there isn't a very good definition of
shutdown and start.  There's the runner itself, that imports the WSGI
application -- this is always run on start, but it's the start of the worker
process, not necessarily the server process (IMHO "starting the server
process" is an internal implementation detail we should not expose).  Silver
Lining also tries to import a silvercustomize module, which is kind of a
universal initialization (also imported for tests, etc).  atexit can be used
to run stuff on process shutdown.  I don't really see a compelling benefit
to another process shutdown technique.  It seems perhaps reasonable to have
something that is run when the actual application instance is shut down, but
I've never personally needed that in practice.  Of course other
configuration settings could be added for different states if they were
reasonably universal states and there was a real need for those.


>
>    - I'm not entirely clear on why you avoid a build process (war-like)
>    prior to deployment. It works fine for appengine - but you don't have it's
>    constraints.
>
> In my own experience with App Engine I found it to be a useful constraint
-- it was not particularly hard to get around (at least if you understand
the relevant tools) and while App Engine has annoying constraints this
wasn't one of them.  Of course I couldn't use lxml at all on App Engine, and
I agree we shouldn't accept that constraint, but for the majority of
libraries that are portable this isn't a constraint.

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