Windows上的django-admin.py和virtualenv问题

Question

In my system there is Django 1.2.3 installed system wide:

C:\>python -c "import django; print django.get_version()"
1.2.3
C:\>django-admin.py --version
1.2.3

Then there is a virtual environment called venv in C:\\dev where I installed Django 1.2.4:

C:\> dev\venv\Scripts\activate.bat
(venv) C:\> python -c "import django; print django.get_version()"
1.2.4
(venv) C:\> django-admin.py --version
1.2.3

My questions:

1. Why django-admin.py reports version 1.2.3, if the current Python (virtual) environment has django 1.2.4 installed?
2. How can I use Django's 1.2.4 django-admin.py automatically when venv is active?

Additional info:

• virtualenv version: 1.5.1, Python version 2.7
• command used to create venv : C:\\dev\\> virtualenv --no-site-packages venv

• (venv) C:\\> echo %PATH%

  C:\\dev\\venv\\Scripts; ...other paths...

• shebang of django-admin.py in venv : #!C:\\dev\\Scripts\\python.exe

Hope you can help, many thanks.

Answer 1

This is because your windows has associated .py extension with the globally installed python.exe . Therefore when you type django-admin.py , even though you're in a virtualenv, the global python is invoked, and it in turn finds your global django installation in its own site-packages. Try python django-admin.py to circumvent the association.

Answer 2

As shanyu already explained, it is because of *.py file associations made to your Python install executable instead of your virtualenv. However, to answer your second question differently, I solved this problem by creating a django-admin.bat in my virtualenv's Scripts directory. Its contents?

@echo off
python %VIRTUAL_ENV%\Scripts\django-admin.py %*

Now you can use django-admin startproject <project_name> . The necessary PATH and VIRTUAL_ENV environment variables should have already been set correctly by virtualenv when you activated the environment.

Answer 3

我只是键入了django-admin ，没有.py文件扩展名，并为我工作。

Answer 4

I had to point the "global python.exe" to my virtualenv in my project so I created my own activate.cmd

set THE_PATH=c:\my-envs\my-specific-env\Scripts
ftype Python.File="%THE_PATH%\python.exe" %%1 %%*
%THE_PATH%\activate.bat

It changes the the file type association using windows command 'ftype'.

Answer 5

I had a similar problem on linux when I tried to use an already exisiting django project with a later installed virtualenv.

Is it possible that django-admin.py of django 1.2.4 is not on your path but that django-admin.py of your django 1.2.3 install is?

That would explain your output from

C:\> dev\venv\Scripts\activate.bat
(venv) C:\> python -c "import django; print django.get_version()"
1.2.4
(venv) C:\> django-admin.py --version
1.2.3

because the python command is on the path of your virtualenv but the django-admin.py file might not be.

As to your second question (assuming my guess above is correct): sym-link the django-admin.py file into your C:\\dev\\venv\\Scripts directory, although I am not sure how that works on windows (are you using Cygwin?).

Of course you can always call it as python C:\\path\\to\\django-admin.py (since the right python version is called) but of course that is a lot of typing.

Answer 6

i used Philip Nelson's solution but had to add quotes for spaces in my filename:

python "%VIRTUAL_ENV%\\Scripts\\django-admin.py" %*