Il giorno 14/apr/2011, alle ore 09.53, Graham Dumpleton ha scritto:
> On 14 April 2011 16:57, Alice Bevan–McGregor <alice@goth...> wrote:
>>> 3. Define how to get the WSGI app. This is WSGI specific, but (1) is
>>> *not* WSGI specific (it's only Python specific, and would apply well to
>>> other platforms)
>> I could imagine there would be multiple "application types":
>> :: WSGI application. Define a package dot-notation entry point to a WSGI
>> application factory.
> Why can't it be a path to a WSGI script file. This actually works more
> universally as it works for servers which map URLs to file based
> resources as well. Also allows alternate extensions than .py and also
> allows basename of file name to be arbitrarily named, both of which
> help with those same servers which map URLs to file base resources. It
> also allows same name WSGI script file to exist in multiple locations
> managed by same server without having to create an overarching package
> structure with __init__.py files everywhere.
+1 for this
uWSGI started with module-approach configuration only (as gunicorn) but
i added support for wsgi-file as soon as i realized that file-based approach is a lot more useful/handy
(no need to make mess with the pythonpath or add __init__.py file all over the place as Graham said).
Pinax (as an example) has a deploy/pinax.wsgi file that you can use as an entry point for your app independently by your filesystem/pythonpath choices.
It worked (at least for my company where we host hundreds of WSGI apps) 100% of the time and without users pain. I cannot say the same for the module approach
(yes, a lot of users are not very confortable with PYTHONPATH/sys.path.... probably they should change work but why destroying their life when we have already a solution
working by years :P )