Hi,

I'm looking for a production wsgi server for Django and found aspen.
I personally prefer an application server written in python with a
reverse proxy out front, so aspen looks like a good fit for me.

Anyway couple comments regarding the Stephane installation
instructions.

1) The symbolic links to from 2.4->2.x don't work on Windows.  This
took me awhile to figure out.

2) The module path doesn't match the one described in:
http://www.djangoproject.com/documentation/tutorial01/

I have to admit I am bit confused by the way module path is handled by
Django, so bare with me.

The tutorial shows to creation of a site with apps.  I assumed in you
example that www.example.com was the site and foo was the app.

When using Django's development server, the site is run from the site
directory.  In your case www.example.com.

This is where it gets interesting.  Django then puts the site
directory AND THE PARENT of the site directory into the module path
when the development server is started.

This is confusing to me, but it means the django development server
can be started from the site directory and modules can still be
referenced as site.modulename.

To get aspen to work the same way, I added the following line to
grapelli.py:

sys.path.insert(0, os.path.join(aspen.paths.root, ".."))

This assumes that the magic __ path is in the site directory and that
aspen is started from the site directory.

I hope that makes some sense.

Christopher,

 > I'm looking for a production wsgi server for Django and found
 > aspen. I personally prefer an application server written in
 > python with a reverse proxy out front, so aspen looks like a
 > good fit for me.

Thanks for giving Aspen a whirl. That's a perfect use-case for Aspen.

 > Anyway couple comments regarding the Stephane installation
 > instructions.

Since releasing Stephane I've taken a different strategy by
adding Django glue code directly to Aspen. Can I ask that you try
out the development snapshot?

   http://www.zetadev.com/software/aspen/#snapshot

You'll find instructions for using Django as both an Aspen "app"
and "handler:"

http://www.zetadev.com/software/aspen/trunk/doc/html/api-apps-django....
http://www.zetadev.com/software/aspen/trunk/doc/html/api-handlers-dja...

Actually, I'm doing tons of development right now using Django
with an Aspen handler that I'm calling "scrimplates." This isn't
documented yet, but here's the source:

http://aspen.googlecode.com/svn/trunk/lib/python/aspen/handlers/djang...

Hope that gives you some pointers. Aspen really needs some
lovin', but I've been swamped for the past couple months. Maybe
we'll see an 0.8 release in July? /me crosses fingers

Thanks again for your interest and questions. I'm heading into
the woods now but I'll check in on Monday.

peace,
chad

Christopher,

Also in the dev snapshot, you'll find that __/lib/python works as
well, so no need for the symlink:

http://www.zetadev.com/software/aspen/trunk/doc/html/api-paths.html

chad

Hi Chad,

I'm getting around to trying the trunk version.  What is the
difference between an app and a handler?  Which do you recommend that
I use?

Thanks,

Chris

To get the trunk version working the way I wanted, I did the
following.

Created apps.conf which allows me to serve files from /static and
django everywhere else.

/ apps.django_:wsgi
/static apps.static:static

Created aspen.conf:

[main]
address = :8000

[django]
settings_module = sitename.settings

aspen is run from the django site root directory, hence aspen root
directory = django site root directory.
This is same as using django's manage.py runserver

Applied the following changes.

The first changes adds '..' to the path just as manage.py runserver
does in Django

The second change fixes a bug with miss named object

Index: apps/django_.py
===================================================================
--- apps/django_.py     (revision 215)
+++ apps/django_.py     (working copy)
@@ -24,6 +24,10 @@
         os.environ['DJANGO_SETTINGS_MODULE'] = settings_module

+sys.path.insert(0, os.path.join(aspen.paths.root, ".."))
+
+
+
 # Instantiate Django's WSGI handler.
 # ==================================
 # This is then wired up to the website root in __/etc/apps.conf.
Index: apps/static.py
===================================================================
--- apps/static.py      (revision 215)
+++ apps/static.py      (working copy)
@@ -1,5 +1,5 @@
 from aspen import configuration
-from aspen.handlers.static import static as static_handler
+from aspen.handlers.static import wsgi as static_handler
 from aspen.utils import find_default, translate

Chris,

 > I'm getting around to trying the trunk version.

Sweet!

 > What is the difference between an app and a handler?

Simple: apps are tied to directories, handlers to files.

 > Which do you recommend that I use?

If you're satisfied with Django's URL routing then stick with an
app mounted at the root (/). If you find Django's URL routing to
be cumbersome, then check out the Aspen's Django handlers.

chad

Chris,

Perfect!

Awesome!

So you're starting aspen within your Django project directory?
Where do you have your static files? Is Aspen serving them correctly?

Aspen is designed so that your Django project directory and
static files directory would be in the following places:

   www.example.com/__/lib/python/myproject/
   www.example.com/static/

Then you would start aspen in the www.example.com directory.

Thanks for catching this bug. Fixed in r216.

chad

Yes

www.example.com/static
www.example.com/djangoapp1/..
www.example.com/djangoapp2/..
www.example.com/settings.py

And yes aspen serves them correctly.

I know this isn't how you intend to use aspen, but it most closely
models the structure of the manage.py runserver django command.

To me it feels odd to put my application code in the magic __
directory.  I could see putting third party libs there, but I want my
application code in site's root directory.

Chris

Chris,

That's helpful, thanks. And you also have a __ dir under
www.example.com, with etc/{aspen,apps}.conf?

I love that you just tweaked Aspen to do what you want. That's
part of the power of a pure-Python server. We've danced around
this filesystem layout question before, and I expect to address
the issue more fully when I have some good chunks of time. In the
meantime workarounds of the sort you found are the best bet.

Thanks for your experimentation and let us know what other issues
or successes you meet with.

chad