Why are you using: sudo python3.4 -m venv --without-pip venv
vs: python3.4 -m venv The whole point of virtual environments is that you create them as your own user. You don’t want to create it as root. Also, why use —without-pip? You want pip to be installed so that after you activate the virtual environment you can then run pip from the virtual environment to install packages in that same virtual environment. > On 11 May 2016, at 5:22 PM, Jaqen Nki <[email protected]> wrote: > > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
