Description of problem: python27-python-pip that is under test currently (rhscl-2.4) contains python27-python-pip-8.1.2-1.el7. This version should be used when invoking pip, but system one is used instead. See bellow. Version-Release number of selected component (if applicable): "name": "rhscl-beta/python-27-rhel7", "release": "17" How reproducible: # s2i build git://github.com/mnagy/stress_test brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/rhscl-beta/python-27-rhel7 python-sample-app --context-dir=sti-python/test-app # docker run -ti <image ID> bash (app-root)rpm -q python27-python-pip python27-python-pip-8.1.2-1.el7.noarch (app-root)pip -V pip 7.1.0 from /opt/app-root/lib/python2.7/site-packages (python 2.7) (app-root)declare -p PATH declare -x PATH="/opt/app-root/bin:/opt/rh/python27/root/usr/bin:/opt/app-root/src/.local/bin/:/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" Actual results: system pip (7.1.0) is used Expected results: collection pip (8.1.2) is used
This is caused by the activation of virtualenv which ignores installed versions of pip, setuptools, wheel and argparse and instead bundles it's own which it then installs into the virtual environment.
This is actually this PR: https://github.com/sclorg/s2i-python-container/pull/159 There were reasons to use virtualenv, so unless there are some known issues with current solution, I'd say this is more a feature than a bug.