|Awesome - the Python cartridge needs some love.|
* take away the versions of Python (2.6, 2.7, 3.3) as a selection of a type of cartridge when creating an app, and make one default (I'd suggest 2.7). Then, if a user wants a different version, then:
1) User locally creates a `openshift.yml` or like-file with a variable in it: `runtime: python-3.3` or `runtime: python-2.6`.
2) The git push triggers a search for a `openshift.yml` then uses the appropriate python (system, /opt/python-3.3, etc)
3) Activates the virtualenv
Some examples that already do this: dotcloud , Heroku 
* The creation or activation of the virtual environment be triggered by the presence of requirements.txt with something like the following steps:
1) if first time, `$ virtualenv PYTHON_APP`
2) then do a `(PYTHON_APP) $ pip freeze` to see what is currently installed, and compare it with requirements.txt, or just look at the git diff.
3) if there's a difference, install/uninstall the missing/added packages
An example: Heroku 
* Allow choices of the default server within some apps, like Django's run_server (while not web scalable now, there are core development plans in the works), gunicorn, etc as well as wsgi. Something defined in the openshift.yml file to declare what type to use, e.g. `server: django_gunicorn`. Example: gondor.io 
* Maybe this is more of a pull request - but for our examples we give, don't suggest folks to declare a django app like "django>=1.3" - that will break with django 1.4, 1.5 etc available. Django apps made on 1.3 are _not_ compatible with 1.4 +. If a user codes in 1.3, follows instructions as our examples show , when a git push happens, you pull down the latest Django release, not necessarily 1.3. This would be mitigated with a requirements.txt but please don't suggest "at least", encourage folks to pin them hard. Heroku  does suggest this too, and is reflected in Gondor's  example.
* Do we support Python packages that contain C extensions? Like PIL, lxml, numpy, matplotlib, etc?
* Python community is really embracing PyPy. I'd highly suggest supporting a cartridge like that.
* My pain-point for Django is setting up the environment with the DJANGO_SETTINGS_MODULE. With Heroku, it's quite easy to set environment variables . This may be more of a general RHC command, but it would be ideal to do something like `rhc config:add DJANGO_SETTINGS_MODULE=mydjangoapp.settings` and that translates to an `export` statement within bash on the Node.
On Mar 27, 2013, at 9:55 AM, Mrunal Patel <mpatel redhat com> wrote:
In the same spirit as the PHP related posts, I am starting this thread so Python developers could