Pyvenv is actually broken on ubuntu 14, so I use this workaround: sudo python3.4 -m venv --without-pip venv
Ive used sudo pip3 install flask pip3 install flask and they both install to the same place and heres the which commands: (venv) kien1@kien1pv:/var/www/site1/FlaskApp/FlaskApp$ which python /usr/bin/python (venv) kien1@kien1pv:/var/www/site1/FlaskApp/FlaskApp$ which python3 /usr/bin/python3 (venv) kien1@kien1pv:/var/www/site1/FlaskApp/FlaskApp$ which pip /usr/bin/pip (venv) kien1@kien1pv:/var/www/site1/FlaskApp/FlaskApp$ which pip3 /usr/bin/pip3 Heres some info I found describing exactly the pyvenv issue. Maybe I can see if ubuntu 16 has this fixed, and test pyvenv on that version. https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847 “ 1) User wants to pip install something into their ~/.local directory. Having python3-* packages installed does not give them pip3. They have to apt-get install python3-pip. If they try to `pip3 install foo` it will try to install it into the system dist-packages and this will fail with a permission denied. They must `pip3 install --user foo` and it will end up in their ~/.local/lib/pythonX.Y/site-packages directory, and it will be importable by the system Python. All of this works right out of the box today: % pip3 install --user nose2 [...] % python3.4 -c "import nose2; print(nose2)" <module 'nose2' from '/home/barry/.local/lib/python3.4/site-packages/nose2/__init__.py'> 2) User wants to pip install something into the system package path. Again they must install python3-pip, and this time they must use `sudo pip3 install foo`. foo gets installed into /usr/local/lib/python3.4/dist-packages. All of this works right out of the box today: % sudo pip3 install nose2 [...] % python3.4 -c "import nose2; print(nose2)" <module 'nose2' from '/usr/local/lib/python3.4/dist-packages/nose2/__init__.py'> 3) Use creates a virtualenv and wants to install foo into the virtualenv. Regardless of whether --system-site-packages is used or not, and regardless of whether pyvenv-3.4 or virtualenv is used, the virtualenv should already contain `/my/venv/bin/pip` and the user should be able to enter the venv and run `pip install foo`. This should install foo into /my/venv/lib/pythonX.Y/site-packages and have it be importable. This latter is the use case that's currently broken with pyvenv-3.4 due to the disabling of ensurepip, so this is the use case we need to fix. System pip package shouldn't enter into the picture. The question we have to answer, IMHO, is whether we want ensurepip to use the recursively bundled pip (and its dependencies) or to rewheel system pip and dependencies (in which case we'd need to handle the circular apt dependencies from python3.4->python3-pip). I think the determining factor should be Debian policy w.r.t. build-from-source. Wheels are just zips so unzipping the two bundled wheels results in all the recursive source files contained within the wheels. But how are the wheels built to be included in the tarball? That recipe must be embodied in the Debian package so that the bundled wheels (with their own vendored libraries) can be completely reproduced from upstream source. If it's not possible to do that reproducibly, then we need an approach like rewheel. “ -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
