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 1.2.4 django-admin.py автоматически, когда активен 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, даже если вы находитесь в виртуальной среде, вызывается глобальный питон, и он, в свою очередь, находит вашу глобальную установку django в своих собственных пакетах сайтов. Попробуйте python django-admin.py, чтобы обойти ассоциацию.

Answer 2

У меня была аналогичная проблема на Linux, когда я пытался использовать уже существующее место проекта Джанго с позже установленного 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 не может быть.

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

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

Answer 3

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

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

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

Answer 4

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

питона "% VIRTUAL_ENV% \ Scripts \ django-admin.py" % *

Answer 5

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

Answer 6

я должен был указать «глобальный python.exe» к моему virtualenv в моем проекте, поэтому я создал свой собственный activate.cmd

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

Это изменяет тип ассоциации файл, используя окна команду «FTYPE».