Can't make virtualenv with Python3

I'm trying to migrate my web app to django16 so I've deleted my original app and now trying to set up the virtual env using django 1.6 and python 3--

following the wiki I tried

mkvirtualenv --python=python3 django16

but got the error

The executable python3 (from --python=python3) does not exist

I'm stumped.

I already had set up a virtual env with python 2.7 (suggestion: move the note re python 3 to the top of the instructions) but wasn't sure how to "delete" it (I am inexperienced with this) — could that have something to do with it?

As an additional question: when I deleted my web app it kept the source files for the app. Is there any easy way to move them to my new virtualenv, so I can just run the app under django 1.6?

Hi there - Django 1.6 is the our system default for Python 3.3 so perhaps you don't need a virtualenv? Alternatively, I think --python=python3.3 should do the job.

Ah, then I don't need a virtualevn, so much the better, thanks --

So just make a new wep app -- how do I move the existing files (back)?

Just put it in a new directory and then start a bash console to copy the files.

(Sorry for typos/brevity - posting from phone)

I'm having the same problem with creating a virtualenv, and specifying --python=python3.3 doesn't do the trick. Console output below:

13:24 ~ $ mkvirtualenv --python=python3.3 django1_7                                             
The executable /home/bjorncooley/python3.3 (from --python=/home/bjorncooley/python3.3) does not exist

I can execute python3.3 from the command line, as well as python3 and python3.4, but I get the same error as above if I try to create a virtualenv with them. Any help much appreciated!

I worked around the problem by creating the virtualenv from within the /usr/bin directory, but would still be curious why this is happening/possible solutions.

You need to specify the full path to the python executable.

Ok, thanks.

sorry none of this helps me. following your instruction I get a error. Your instructions on how to set up a virtual environment to be honest really suck. This is something that would definitely put me off buying your service. I need to you django 1.7 and Python 3 something you don't offer. I'm not a Unix user and to be honest non of this helped at all. I would like to get a simple set of instructions on how to do this. Telling me to add a full path to executable doesn't tell me very much

Hi there -- sorry to hear you're finding the instructions confusing. What error are you getting, and where is it showing up?

Oh, and just to make sure we're on the same page -- these are the instructions you're following, right?

So, as I see now, the tutorial still doesn't work.

Do I need a virtualenv if I want to use battieries that are not on ?

btw --python=python3.3 does not work and --python=python3.4 does neither

12:47 ~ $ source
12:48 ~ $ mkvirtualenv --python=python3.4 django17
The executable /home/Wanderwichtl/python3.4 (from --python=/home/Wanderwichtl/python3.4) does not exist
12:48 ~ $ mkvirtualenv --python=python3.3 django17 
The executable /home/Wanderwichtl/python3.3 (from --python=/home/Wanderwichtl/python3.3) does not exist

The workaround of bjorncooley works :) Just change the directory to this path and later you can change back to your normal path. (I dont know how to direct pass the path^^)

Thanks for confirming that :-) What Glenn meant by specifying the full path to the Python executable was this:

mkvirtualenv --python=/usr/bin/python3.4 django17

That is, mkvirtualenv needs to know which directory the python3.4 file is in, so if you specify it on the command line then it will work. bjorncooley's workaround works because by changing directory to /usr/bin/, you set things up so that mkvirtualenv can find it in the current working directory.

To add to the conversation, the following commands also work to create virtual environments on Pythonanywhere, assuming you're in the .virtualenvs directory:

$ virtualenv --python=python3.4 --no-site-packages your_project_name
$ source
$ workon your_project_name
(your_project_name)$ which pip
(your_project_name)$ which python
(your_project_name)$ python --version
Python 3.4.0
(your_project_name)$ pip install django==1.7.1

Definitely tested and working. Not sure if there's a huge difference between mkvirtualenv & virtualenv for creating environments, but I've had no problem with this. Don't forget to point your Pythonanywhere wsgi file at the new virtual environment and restart the app from the dashboard.

one difference is that mkvirtualenv wants the full path for the python version, so --python=/usr/bin/python3.4, not just --python=python3.4...

Can i install python3.6.1 ?

Unfortunately not -- though we're planning to do a new system image sometime in the not-too-distant future that will provide more recent versions of Python.

mkvirtualenv --python=/usr/bin/python2.7 testproject

File "<stdin>", line 1 mkvirtualenv --python=/usr/bin/python2.7 testproject ^ SyntaxError: invalid syntax

Is there a reason why copying your instruction gives me an error? Thanks

You're typing it into a Python console and not into a Bash console.

Any reason why I would get the same error message when trying to create a new virtual env? ie.

$ mkvirtualenv --python=/usr/bin/python3.6 myVenv
   The path /usr/bin/python3.6 (from --python=/usr/bin/python3.6) does not exist
  1. I'm in a Bash console
  2. I've tried with and without the path.
  3. I notice my python version is 2.7.6 (can that be changed yet to 3.X?)

Any reason why I would get the same error message when trying to create a new virtual env? ie.

$ mkvirtualenv --python=/usr/bin/python3.6 myVenv
   The path /usr/bin/python3.6 (from --python=/usr/bin/python3.6) does not exist
  1. I'm in a Bash console
  2. I've tried with and without the path.
  3. I notice my python version is 2.7.6 (can that be changed yet to 3.X?)

Ah, don't worry about it. Just looked in usr/bin and discovered the latest version seems to be 3.5.

So this then worked:

mkvirtualenv --python=python3.5 myVenv

It looks like you're using quite an old system image -- you're on "classic", which goes up to Python 3.5, while our most recent, "earlgrey" has 3.7 (and more recent versions of the other Pythons, for example 2.7.12 instead of 2.7.6). We can switch you over if you like -- it's just a simple update to a single DB field on our side -- but there are some caveats -- see this blog post for details.

Thanks Giles. Yes, it will break a dependancy that for the time being I'd prefer to retain. So I'll leave it for now and, as per blog page you referenced, when I'm ready I'll pass on a request from the "Send feedback" button (acknowledging I'm aware of the blog contents). Cheers!

No problem, glad to help!