Develop Reference

How to install (run) Jumo (Python/Django) on localhost

I am trying to run Jumo open source platform ( https://github.com/jumoconnect/openjumo) on my local machine (Windows 7). I have Python and Django installed and it works - I can create new project without problems, but I am not sure how to set existing project and make it work.
I am not experienced with Python/Django, so first I need to know whether it is hard task or not. I guess it's much complicated then installing WordPress or Joomla, but does that require a lot of work in order to set it up?
Can someone write some kind of guide if it is not too complicated? Or if there is some tutorial that explains how to do that, that would be great.
Just to be clear, I am not trying to learn something in one day, just want to see if this first step in using this platform is too hard, and if it's not, I'd continue learning, because this is exactly what I need for one project.
I use Python 2.7 and Django 1.3.1
Thanks

This project has a lot of external requirements which are not listed anywhere and unless you are comfortable and familiar with django, I wouldn't recommend installing it. Here are some but not all of the requirements that you'll need running:
Celery and django-celery
RabbitMQ (a broker for Celery), or another broker but then you'll have to edit settings.py again.
memcached (this is optional, as you can use django's own session middleware for development), but if you simply download the code and try to run it, you'll run into an error since the default settings.py has the default middleware commented out.
grappelli
django-jenkins (not required, but again, unless you edit the default settings.py, you'll get errors).
django-tastypie
django-debug-toolbar
Data science toolkit server

as you may know Django is a powerful web framework and Python is a programming language, for python itself you need more than a few months to become some kind of expert.
it's very easy to start, but not that easy to learn the whole stuff. Django is one of the most or maybe the most powerful web frameworks (beside Ruby on Rails).
my advice to you:
learn python's basics (there's many books such as dive into python,
...)
learn Django basics (Django Book)
use Django on a Gnu/Linux (for example Ubuntu)
learning basics of Django can be done in a few weeks.
consider deploying a Django website is not that easy. you need to know a little about Apache web server.
www.djangoproject.com
note that in python (like other programming languages) you need to define working path. errors mentioned in question's comments usually caused by this.
also you should check Python installation path. sometimes these kinds of errors occurs when there is a project with the same name as yours in python installation path.

Installing Sphinx on App Engine - possible?

Following up on my last year's question on documentation, I now want to get started and try out Python-based Sphinx for putting together the developer documentation for a PHP CMS I've been working on.
Instead of setting up Python locally on my workstation, I would like to run it on a publicly accessible web server from the start. All the web hosting packages I have access to run on the LAMP stack, and I'm reluctant to buy Python-based hosting. I am very interested in the Google App Engine, the free quotas they provide will do for me a hundred times over, and even if not, their pricing looks very reasonable.
Now I have zero knowledge of Python - getting Sphinx to work would be my first contact with it - and very little time. As far as I understand, the platform and python libraries the App Engine provides are very compatible to a standard Python library but not identical.
So my question is:
Can Sphinx run on App Engine at all?
Is installing Sphinx on the App Engine as straightforward as if I would install it on top of a normal Python installation? Or will the App Engine's environment require tweaking of the source code that I can't perform in reasonable time with my current level of Python?
Should I be installing Sphinx on a local server and a "normal" Python stack instead first?
Does anybody know any helpful How-to's, tutorials or other resources for this?

You do not need to install Sphinx on GAE at all.
You use Sphinx to create a directory of static HTML, CSS and JS. When this step is finished, you simply upload the output from Sphinx -- in it's entirety.
The output from Sphinx (HTML, CSS and JS) is simply served from one place. You upload the documentation from where you created it to GAE as static files and serve them. Done.
There's no "install on a web server" aspect to Sphinx at all. Sphinx is not a web application; it does not run on your web server. You run it in development briefly to publish the documentation to HTML, LaTeX or whatever. Once you've created the static HTML files, you no longer need any part of Sphinx anywhere.
Can Sphinx run on App Engine at all?
I suppose it can, but you never need to.
Is installing Sphinx on the App Engine
as straightforward as...
It doesn't matter, because you don't install it there. You install it on your workstation and use it on your workstation.
Should I be installing Sphinx on a
local server and a "normal" Python
stack instead first?
Don't install it on a server. Install it on your workstation.
Does anybody know any helpful
How-to's, tutorials or other resources
for this?
If by "this" you mean "installing on a web server", then then answer is "no". One does not install it on a web server. So there are no how-to's, tutorials or resources for "installing on a web server".
If by "this" you mean "creating documentation with Sphinx", then the answer is "what's wrong with https://www.sphinx-doc.org? What do they lack?
I would like Sphinx's "engine" that
turns the input (consisting of reST
files) into HTML/CSS/JS to be
accessible from anywhere to make me
(and possible other contributors)
independent from a specific
workstation.
Sphinx is like a compiler. Everyone has their own copy on their workstation. They download the document source, make changes, commit the source changes, and upload the resulting document.
serve the generated documentation from
the same place.
Correct. After you download the source, make changes, regenerate the document and commit the changes, you upload the resulting document so it will be served from one -- and only one -- place.
Sphinx is a compiler. It is not a "web engine". It's a simple compiler that simply compiles your documentation into HTML so it can be served.

Interesting project! The main issue you're going to run into is that of filesystem access: The filesystem on App Engine is read-only, and based on looking at the source, Sphinx is fairly hard-coded to use the filesystem for output. It also expects to read the configuration file and input files from the local filesystem, which would make building docs for anything other than projects bundled with the app tricky.
It is possible to work around this, but it would require writing a simple virtual filesystem that uses the App Engine datastore, and using monkeypatching to make it work with the regular Python file interface. That's rather advanced for a "new to Python" project!
One other thing you might want to consider if you were pondering allowing users to upload projects to be documented: The Sphinx configuration file is in Python, so executing it could be dangerous - a user could do nasty things to your app with a malicious configuration file!

The difference between deployment locally via dev_appserver and remotely via appcfg has been - in my experience - limited to which of the two commands I execute. That said, I've no experience with Sphinx.

Sphinx compiles documentation, running it on a webserver makes as much sense as running gcc on a webserver.

What modules ought I to consider in Python if I wish to use CGI sessions?

Given that I know no web frameworks in Python and would like to keep it Very Simple at the moment (as I am Very Stupid), for what is a prototype of sketchy longevity, are there any streamlined, simple, "batteries-included" modules for this? (It is also too early in my Python career to evaluate frameworks, select one, and learn it.) I see a module named "Cookie," which could serve as a foundation, but nothing session-specific.
I'm familiar with the basic session concepts, having used them in classic ASP and gotten into the nuts-and-bolts of them in Perl, but I am not seeing a lot for Python. Beaker looks interesting, but then the documentation seems to require middleware with WSGI and I'm back to the frameworks problem.
I've found an old recipe on ActiveState for sessions, which could obviously use some buffing up. The information being held is not anything anyone would mind having been grabbed, so while I am normally quite security conscious, I would be willing to be a little bit more lax with this prototype.
Or is this a "roll-your-own" problem?
I will be using Python 2.6 on IIS 7.0.

I think the web2py (web framework) is easy enough for you. I think it is the simplest approach of making a website or webservice. It will be also easier, than to understand Cookie or the other modules of python related to web-things.
You can start a session, by just typing:
session.your_session_name = "blabla" # or whatever you want to store
To make a cookie, just look here.
In web2py you don't have to configure anything. Just download it and start web2py.py. (you must have python 2.6 < installed.) You can also find some examples and a web-slide.
The Python Cookie module does nothing more than to hold some values in a dictonary-like object, but I think you have to store it yourself on your harddisk.

CherryPy is worth looking into. Yes it is a framework, and yes it requires WSGI, but it is extremely lightweight compared to other more robust alternatives.
There is another question that was answered on SO that gives a brief example on how to manage sessions with CherryPy. As you can see it makes it very easy to get up and running quickly.
Lastly, here is a little document about setting up IIS for use with CherryPy.

WSGI is not a framework, nor does it require that you choose one -- it's THE standard way to run any Python web app framework on any Python-supporting web server, including a CGI one. If you have a WSGI application named app, and want to run it on CGI, see the docs and use wsgiref.handlers.CGIHandler().run(app), as the docs say.
So, you can perfectly well use Beaker via WSGI (on top of CGI) -- e.g., take the example in Beaker's docs and just add (the needed imports and) the run call above (using the wsgi_app object that example constructs, plus of course a session.save and as well needed as, again, the Beaker docs explain right afterwards).
Rich or heavy frameworks have their place but so do lightweight, flexible components like Beaker -- and WSGI middleware is a great way to leverage such components without requiring any "framework-y" arrangements, just good old WSGI (on top of CGI or anything else).
BTW, the best way to run WSGI on IIS might be isapi-wsgi (I can only say "might" because I have no IIS installation on which to test it;-). But as long as you code to WSGI (with any framework or with none at all), that will only be an optimization -- your application won't change (net of what handler's run or equivalent method you need to call;-) whether it's running on CGI, IIS via ISAPI, Google App Engine, or any other server-and-interface-thereto combination

Python web hosting: Why are server restarts necessary?

We currently run a small shared hosting service for a couple of hundred small PHP sites on our servers. We'd like to offer Python support too, but from our initial research at least, a server restart seems to be required after each source code change.
Is this really the case? If so, we're just not going to be able to offer Python hosting support. Giving our clients the ability to upload files is easy, but we can't have them restart the (shared) server process!
PHP is easy -- you upload a new version of a file, the new version is run.
I've a lot of respect for the Python language and community, so find it hard to believe that it really requires such a crazy process to update a site's code. Please tell me I'm wrong! :-)

Python is a compiled language; the compiled byte code is cached by the Python process for later use, to improve performance. PHP, by default, is interpreted. It's a tradeoff between usability and speed.
If you're using a standard WSGI module, such as Apache's mod_wsgi, then you don't have to restart the server -- just touch the .wsgi file and the code will be reloaded. If you're using some weird server which doesn't support WSGI, you're sort of on your own usability-wise.

Depends on how you deploy the Python application. If it is as a pure Python CGI script, no restarts are necessary (not advised at all though, because it will be super slow). If you are using modwsgi in Apache, there are valid ways of reloading the source. modpython apparently has some support and accompanying issues for module reloading.
There are ways other than Apache to host Python application, including the CherryPy server, Paste Server, Zope, Twisted, and Tornado.
However, unless you have a specific reason not to use it (an since you are coming from presumably an Apache/PHP shop), I would highly recommed mod_wsgi on Apache. I know that Django recommends modwsgi on Apache and most of the other major Python frameworks will work on modwsgi.

Is this really the case?
It Depends. Code reloading is highly specific to the hosting solution. Most servers provide some way to automatically reload the WSGI script itself, but there's no standardisation; indeed, the question of how a WSGI Application object is connected to a web server at all differs widely across varying hosting environments. (You can just about make a single script file that works as deployment glue for CGI, mod_wsgi, passenger and ISAPI_WSGI, but it's not wholly trivial.)
What Python really struggles with, though, is module reloading. Which is problematic for WSGI applications because any non-trivial webapp will be encapsulating its functionality into modules and packages rather than simple standalone scripts. It turns out reloading modules is quite tricky, because if you reload() them one by one they can easily end up with bad references to old versions. Ideally the way forward would be to reload the whole Python interpreter when any file is updated, but in practice it seems some C extensions seem not to like this so it isn't generally done.
There are workarounds to reload a group of modules at once which can reliably update an application when one of its modules is touched. I use a deployment module that does this (which I haven't got around to publishing, but can chuck you a copy if you're interested) and it works great for my own webapps. But you do need a little discipline to make sure you don't accidentally start leaving references to your old modules' objects in other modules you aren't reloading; if you're talking loads of sites written by third parties whose code may be leaky, this might not be ideal.
In that case you might want to look at something like running mod_wsgi in daemon mode with an application group for each party and process-level reloading, and touch the WSGI script file when you've updated any of the modules.
You're right to complain; this (and many other WSGI deployment issues) could do with some standardisation help.

Common errors when moving a django app from dev to prod?

I am developping a django app on Windows, SQLite and the django dev server . I have deployed it to my host server which is running Linux, Apache, FastCgi, MySQL.
Unfortunately, I have an error returned by the server on the prod while everything ok on the dev machine. I've asked my provider for a pre-production solution in order to be able to debug and understand the problem.
Anyway, what are according to you the most likely errors that can happen when moving a django app from dev to prod?
Best
Update: I think that a pre-prod is the best way to address this kind of problem. But I would like to build a check list of what must be done before to put in production.
Thanks for the very valuable answers that I received until now :)
Update: FYI, I 've implemented the preprod server and the email notification as suggested by shanyu and I can see that the error comes from the smart_if templatetag that I am using on this new version. Any trick with template tags?
Update: I think I've fixed the pb which was caused I think by the Filezilla FTP sending. I was using the "replace if newer" option which I guess is causing some unexpected results. Using the "replace all" option fix the issue. However, it was an opportunity for me to learn more about deployment. Thansk for your answers.

Problems I typically have include:
Misconfigured productions settings, whether in my production localsettings.py, wsgi/cgi, or apache site files in /etc/sites-available
Database differences. I use South for migrations and have run into some subtle issues when performing my migration on PostgreSQL when it worked smoothly in sqlite.
Static file hosting since I cheat and use the Django server in development
Permissions, both on the file system and within the database
Rare, but possible, network issues preventing me from getting my dependencies, whether on PyPi or some 3rd party site
Ways that I have mitigated these issues:
Use the same database in production and development (in your case, MySQL everywhere)
I've found it is useful to have a "test" environment which mimics production in every way possible (it can be on lower end hardware, or even the same machine). This way, if there are any issues in this "production-like" enivornment, I can solve them without taking my production server offline.
Script everything for repeatable deployments. I use fabric, but zc.buildout or Paver would also work. These tools help reduce typos while deploying and reduce the time to deploy my app.
Use version control (mercurial, git, subversion) and a schema migration tool (like South), so if something does go wrong when you deploy to production, you have the possibility of backing out the changes and allowing production to run on the old code with the old database schema.
I haven't set up an "egg proxy" yet, but I am considering it, to avoid issues when downloading dependencies.
I've found pip's freezing dependencies to be useful, in case a new, incompatible change to a library occurred since I downloaded it initially
Use a web testing framework like Windmill or Selenium to test my application in my "test" environment, so that I can get a lot of test coverage of my system very quickly.

Regarding your case, I can think of 2 simple things that may help you:
You can enable Django to send messages when exceptions occur giving details about them. Look at here for details.
You'll be better off if you set up a test environment on the prod server (say, test.example.com) so that you can check if things will go smoothly or not before you deploy the app.

I believe these were the podcasts I listened to recently (from Pycon 2009):
Locate Django in the Real World (PyCon 2009):
http://advocacy.python.org/podcasts/pycon.rss
Parts 1 to 3
Very good introduction to designing your apps for deployment, in particular for reuse and redeployment.
Regs.