In article <a6b6f2c8-4f5d-4410-92ab-1e81de529...@googlegroups.com>, Miki Tebeka <miki.teb...@gmail.com> wrote:
> > When we deploy, we create a new virtualenv, then do > > "pip install -r requirements.txt". > 1. Do you do that for every run? Well, sort of. We are currently using a single virtualenv per deployment host. Each time we deploy new code, we checkout all the code into a fresh directory, but each of those shares a common virtualenv. As part of the deploy process, we do indeed execute "pip install -r requirements.txt", which picks up any new required packages. Unfortunately, that process doesn't give us a good way to back out a bad update. It's easy for us to revert to an previous version of our code, but we don't have a good way to revert the virtualenv to its previous state. Fortunately, that's been mostly a theoretical issue for us so far. In the future, the plan is to build a complete fresh virtualenv for every deployment. But we're not there yet. > 2. Our ops team don't like to depend on pypi, they want internal repo - but I > guess I can do that with "pip install -f". Listen to your ops team. Right now, we install out of pypi, but that's slow, and on occasion, fails. This is part of why we still use a shared virtualenv, and what your ops guys are trying to avoid :-) Eventually, we'll mirror all the packages we need locally, and pip install out of that. Once we've got that all working, we'll move to a new virtualenv per deployment (which sometimes is several times a day). -- http://mail.python.org/mailman/listinfo/python-list
