django-admin.py и проблема virtualenv в Windows

Question

В моей системе установлена ​​система Django 1.2.3:

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

Затем существует виртуальная среда с именем venv в C: \ dev, где я установил 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

Мои вопросы:

1. Почему django-admin.py сообщает о версии 1.2.3, если в текущей Python (виртуальной) среде установлен django 1.2.4?
2. Как автоматически использовать django-admin.py в Django 1.2.4, когда venv активен?

Дополнительная информация:

• virtualenv версия: 1.5.1, Python версия 2.7
• команда, используемая для создания venv : C:\dev\> virtualenv --no-site-packages venv

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

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

• шебанг django-admin.py в venv : #!C:\dev\Scripts\python.exe

Надеюсь, вы можете помочь, большое спасибо.

Answer 1

Это потому, что ваши окна ассоциируют расширение .py с глобально установленным python.exe. Поэтому, когда вы набираете django-admin.py, даже если вы в virtualenv, глобальный питон вызывается, и он, в свою очередь, находит вашу глобальную установку django в своих собственных пакетах сайта. Попробуйте python django-admin.py обойти ассоциацию.

Answer 2

Как уже объяснил Шаньюй, это из-за ассоциаций файлов * .py, сделанных в вашем исполняемом файле установки Python вместо вашего virtualenv.Однако, чтобы ответить на ваш второй вопрос по-другому, я решил эту проблему, создав django-admin.bat в директории Scripts моего virtualenv.Его содержимое?

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

Теперь вы можете использовать django-admin startproject <project_name>.Необходимые переменные окружения PATH и VIRTUAL_ENV должны быть правильно установлены в virtualenv при активации среды.

Answer 3

Мне пришлось указать «global python.exe» на мой virtualenv в моем проекте, поэтому я создал свой собственный activ.cmd

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

Он изменяет связь типов файлов с помощью команды windows 'ftype'.

Answer 4

Я только что набрал django-admin , без расширения .py, и работал для меня.

Answer 5

У меня была похожая проблема в linux, когда я пытался использовать уже существующий проект django с , установленным позже virtualenv.

Возможно ли, что django-admin.py в django 1.2.4 на вашем пути не , а django-admin.py в вашей установке django 1.2.3 - *

Это объясняет ваш вывод из

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

потому что команда python находится на пути вашего virtualenv, но файл django-admin.py может не быть.

Что касается вашего второго вопроса (если предположить, что мои предположения верны): sym-link файл django-admin.py в вашу директорию C:\dev\venv\Scripts, хотя я не уверен, как это работает в Windows (вы используете Cygwin?).

Конечно, вы всегда можете назвать его как python C:\path\to\django-admin.py (так как называется правильная версия Python), но, конечно, это много печатать.

Answer 6

Я использовал решение Филиппа Нельсона, но мне пришлось добавить кавычки для пробелов в моем имени файла:

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