I have run into this myself a couple of times. Stopping and deleting all containers with "docker-compose rm -f" after requirements update and then starting them again with "docker-compos up -d" fixed that for me.
I agree it's annoying and we should do something about it. virtualenv sounds good if we can set PATH to avoid activating it manually on every command. On Mon, Nov 30, 2015 at 10:35 PM, heith seewald <[email protected]> wrote: > I'm not sure why that started happening -- but I do think using a virtual > env is a good solution. > > On Mon, Nov 30, 2015 at 3:31 PM, Dave Brondsema <[email protected]> > wrote: > > > I was rebuilding my docker environment and ran into a problem. We > install > > directly into the system python location (no virtualenv needed if in > > docker), > > and that location /usr/local/lib/python2.7 is shared between our > > containers so > > they all have the same packages installed at once. This had been working > > fine > > for me. > > > > With my rebuild, I started getting errors with the version of "six" > > because the > > system comes with an older version of "six" and ubuntu has pip set up to > > not > > override that: > > > > Downloading/unpacking six==1.7.3 (from -r requirements.txt (line 45)) > > Downloading six-1.7.3-py2.py3-none-any.whl > > ... > > Found existing installation: six 1.5.2 > > Not uninstalling requests at /usr/lib/python2.7/dist-packages, owned > > by OS > > > > This also happens with "chardet" and "requests" but they happen to be > > newer than > > what we list in requirements.txt And we can't just use the older version > > of > > "six" because paster throws this error: > > > > ... > > pkg_resources.VersionConflict: (six 1.5.2 > > (/usr/lib/python2.7/dist-packages), > > Requirement.parse('six>=1.6.1')) > > > > I tried using ubuntu 15.10 instead of 14.04 (LTS) but it runs into issues > > with > > "requests", quite possibly because the versions are wrong with that too. > > > > We wouldn't want to use wrong versions of any packages anyway, even if we > > could > > somehow force it to work. > > > > So, I am thinking we should actually use a virtualenv inside the > > containers, so > > we get the packages we want and don't get interference from the system > > packages. > > It should be easy to add that to the build steps, but it'll probably > mean > > longer commands when running paster commands, to make sure you're in the > > venv. > > Unless we can find some way to always set the PATH. > > > > I don't know why this started happening all of a sudden though. Any > > ideas? We > > should fix before making a release, since our recommended installation > > path no > > longer works :( > > > > > > > > -- > > Dave Brondsema : [email protected] > > http://www.brondsema.net : personal > > http://www.splike.com : programming > > <>< > > >
