3 ms·

Since the framework and the server(s) can be set up in a multitude of ways (including two-server setups with Apache serving Django and nginx serving static file

Since the framework and the server(s) can be set up in a multitude of ways (including two-server setups with Apache serving Django and nginx serving static files), I'm finding it really hard to believe that you'd be able to distribute a one-size-fits-all Django-WordPress egg. Sure you could have RPMs or Debian packages tailormade for a specific distribution, but WordPress has the advantage that it's a downloadable package that can easily be (S)FTP'd into a folder on a shared host and run, and it'll work with most hosts. You just can't do that with Django-WordPress. Again, I use Django/Python more than PHP these days, so it's not a PHP versus Python thing.

Ixiaus 16y ago
True, there are many possible configurations, but a few (I don't have widespread experience with Python based hosts because most of my Python work has been on my own servers) hosts I've used have mod_wsgi installed with a WSGIDaemon process pointing at the application directory with index.wsgi being one of the index handlers. What you are supposed to provide is an application with a route through an index.wsgi file. In Pylon's case (this is how I have my server setup) index.wsgi is simply loading the Pylons app and providing it as a wrapped "application" class as a callable. Very standard and very easy. As an example, here is the index.wsgi front-controller that loads my Pylons app (note, mine is more complicated than I'm showing here because I use virtualenv to contain the app): from paste.deploy import loadapp application = loadapp('config:/home/my_app/production/production.ini') The host makes sure that the Apache vhost has mod_wsgi configured to run a WSGIDaemon process for the /home/my_app/production directory - typically (in the case of WebFaction) they give you an interface that handles all of that (so you can run multiple apps out of the same top level directory) in the course of creating your "sites", the same exact process you would go through for creating "sites" for a PHP based application. Also, you don't need to tailor RPM's to the distribution, you can package your app as a python egg (which is cross-platform and contains the dependency links in your setup.py). I almost think this is easier than (S)FTP'ing the app up to your host. If your host gives you SSH access (which all $5 a month hosts do as far as I know - the crappier ones put you through a verification process, but a good one will give it to you the minute you are signed up) you can easily rsync the app up and then run "python setup.py whatevercommandyourappuses" and bam - you're good to go. You could even put the database creation steps into the setup.py routine - "python setup.py build", "python setup.py install" <---- build necessary directories, then build your database tables for you. Much safer (and easier) than supplying an install script that can be accessed publicly. I will concede though, that the whole scenario I've just described wouldn't be easy and fast for the average joe due to their inexperience with Python and/or the command line... That kind of thing makes me wonder though why we don't have basic programming courses as a requirement in high-school. If only my father (a lawyer) knew what sed/grep/awk could do for his manipulation of documents... I'm digressing now and I'll stop. I know it isn't a PHP vs. Python thing - it just frustrates me when people make the argument for an inferior tool in favor of ease of use when ultimately (as per the scenario I gave above) the more powerful tool can save you time... I came from PHP land and will not go back - thanks in part to Python and the other methodologies I've learned.

Ixiaus 16y ago

True, there are many possible configurations, but a few (I don't have widespread experience with Python based hosts because most of my Python work has been on my own servers) hosts I've used have mod_wsgi installed with a WSGIDaemon process pointing at the application directory with index.wsgi being one of the index handlers. What you are supposed to provide is an application with a route through an index.wsgi file. In Pylon's case (this is how I have my server setup) index.wsgi is simply loading the Pylons app and providing it as a wrapped "application" class as a callable. Very standard and very easy. As an example, here is the index.wsgi front-controller that loads my Pylons app (note, mine is more complicated than I'm showing here because I use virtualenv to contain the app): from paste.deploy import loadapp application = loadapp('config:/home/my_app/production/production.ini') The host makes sure that the Apache vhost has mod_wsgi configured to run a WSGIDaemon process for the /home/my_app/production directory - typically (in the case of WebFaction) they give you an interface that handles all of that (so you can run multiple apps out of the same top level directory) in the course of creating your "sites", the same exact process you would go through for creating "sites" for a PHP based application. Also, you don't need to tailor RPM's to the distribution, you can package your app as a python egg (which is cross-platform and contains the dependency links in your setup.py). I almost think this is easier than (S)FTP'ing the app up to your host. If your host gives you SSH access (which all $5 a month hosts do as far as I know - the crappier ones put you through a verification process, but a good one will give it to you the minute you are signed up) you can easily rsync the app up and then run "python setup.py whatevercommandyourappuses" and bam - you're good to go. You could even put the database creation steps into the setup.py routine - "python setup.py build", "python setup.py install" <---- build necessary directories, then build your database tables for you. Much safer (and easier) than supplying an install script that can be accessed publicly. I will concede though, that the whole scenario I've just described wouldn't be easy and fast for the average joe due to their inexperience with Python and/or the command line... That kind of thing makes me wonder though why we don't have basic programming courses as a requirement in high-school. If only my father (a lawyer) knew what sed/grep/awk could do for his manipulation of documents... I'm digressing now and I'll stop. I know it isn't a PHP vs. Python thing - it just frustrates me when people make the argument for an inferior tool in favor of ease of use when ultimately (as per the scenario I gave above) the more powerful tool can save you time... I came from PHP land and will not go back - thanks in part to Python and the other methodologies I've learned.