[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Python cartridge enhancements

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 [1], Heroku [2]

* 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 [3]

* 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 [4]

* 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 [5][6], 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 [3] does suggest this too, and is reflected in Gondor's [4] 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 [7]. 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.



[1] http://docs.dotcloud.com/firststeps/quickstart/
[2] https://devcenter.heroku.com/articles/python-runtimes
[3] https://devcenter.heroku.com/articles/python-pip
[4] https://gondor.io/support/django/setup/
[5] https://github.com/openshift/django-example/blob/master/setup.py#L12
[6] https://github.com/openshift/flask-example/blob/master/setup.py#L9
[7] https://devcenter.heroku.com/articles/config-vars

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
chime in on what they feel we should do to improve the Python cartridge user experience.

One of the first things I can think of is adding support for requirements.txt.


dev mailing list
dev lists openshift redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]