convore.json/groups/django-community/virtualenv-and-django/messages.json

[{"user_id": 26414, "stars": [], "topic_id": 35407, "date_created": 1305493343.8943441, "message": "Where i can read about typical workflow with django and virtualenv? As newcomer in python world, i'm a bit confused about how i should use virtualenv with django. As i see it, i should create separated env for each project and deploy whole env to the production server, setup each apache host for use specific python executable and etc. Do i thinking in a right way?", "group_id": 81, "id": 1063421}, {"user_id": 26920, "stars": [{"date_created": 1305523654.0399981, "user_id": 15284}, {"date_created": 1305795290.2525561, "user_id": 14057}], "topic_id": 35407, "date_created": 1305495637.395926, "message": "yes. Something like that. I create a virtualenv for each project. Then on a production server, I can pull the source (which presumably contains a requirements.txt type of deal that got created in dev via the \"pip freeze > requirements.txt\"). On production you can then create a virtual environment and \"pip install -r requirements.txt\". Apache or Nginx or all the other things you might do in production is a little more specific based on the approach you're using for your stack. For me, I just do nginx + gunicorn since it's a little easier.", "group_id": 81, "id": 1063673}, {"user_id": 26414, "stars": [], "topic_id": 35407, "date_created": 1305523289.7664959, "message": "Thx, now its getting more clear =)", "group_id": 81, "id": 1067305}, {"user_id": 20816, "stars": [], "topic_id": 35407, "date_created": 1305533104.3261571, "message": "@tipugin you could also read lincolnloop.com/django-best-practices/ (just as an example) for some base deployment practises", "group_id": 81, "id": 1068499}, {"user_id": 26414, "stars": [], "topic_id": 35407, "date_created": 1305534121.6936209, "message": "@varankin thnks bro =)", "group_id": 81, "id": 1068638}, {"user_id": 28548, "stars": [], "topic_id": 35407, "date_created": 1305535225.689466, "message": "I also like to use the virtualenvwrapper. It holds all environments in a single directory, which helps with testing your app with different settings. At Mozilla one of the common solutions is to provide and share vendor directory with installed packages, so it's downloaded to production server.", "group_id": 81, "id": 1068761}, {"user_id": 33545, "stars": [], "topic_id": 35407, "date_created": 1305647382.469434, "message": "I'd like to have ve initialization build into manage.py http://djangosnippets.org/snippets/2209/", "group_id": 81, "id": 1084426}, {"user_id": 960, "stars": [], "topic_id": 35407, "date_created": 1305652029.1198361, "message": "@kmmbvnr The problem is that VE isn't wanted or needed by everyone.  Including something like that by default is overkill. (speaking as a non-core dev)", "group_id": 81, "id": 1085108}, {"user_id": 33545, "stars": [], "topic_id": 35407, "date_created": 1305703476.883765, "message": "@tswicegood it is true only for open-source project, running under different python versions and env, but if you have commercial project, having the same consistent environment for all dev is important. Btw, having ve setup in manage.py makes it easy to run under any IDE without sophisticated configuration.", "group_id": 81, "id": 1094078}, {"user_id": 960, "stars": [], "topic_id": 35407, "date_created": 1305755760.8521211, "message": "It's a problem that can be addressed at multiple levels, but something I don't think Django ever should (or will) be that opinionated about.", "group_id": 81, "id": 1103700}, {"user_id": 960, "stars": [], "topic_id": 35407, "date_created": 1305755738.3479631, "message": "@kmmbvnr I disagree that it's only important to OSS.  I've deployed plenty of applications where the \"virtualenv\" was literally the OS being built a particular way to deploy one application.", "group_id": 81, "id": 1103696}, {"user_id": 33545, "stars": [], "topic_id": 35407, "date_created": 1305767424.9529181, "message": "@tswicegood If you have so custom deployment script, there is no problem to include just 2 lines and call django.core.management.execute_manager directly. It is not the point to break dev env and ide integration with explicit ve setup. Remember Zen: \"practicality beats purity\"", "group_id": 81, "id": 1105376}, {"user_id": 960, "stars": [], "topic_id": 35407, "date_created": 1305815171.0579691, "message": "@kmmbvnr A choice was made with Django to be explicit over implicit.  Relying on an external tool that's nice in some (most?) instances is a choice I never see Django making.  They'd have to start shipping `virtualenv` and I just don't see that happening.", "group_id": 81, "id": 1111600}, {"user_id": 960, "stars": [], "topic_id": 35407, "date_created": 1305815227.124398, "message": "Just as you can point to line 9, I can also point to lines 1 - 8 which would negate virtualenv by default.", "group_id": 81, "id": 1111605}]