Подтвердить что ты не робот

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

В моей системе установлен 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

Мои вопросы:

  • Почему django-admin.py сообщает версию 1.2.3, если текущая среда Python (виртуальная) установлена ​​django 1.2.4?
  • Как я могу использовать 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...

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

Я просто набрал django-admin без расширения .py файла и работал у меня.

Ответ 4

Мне пришлось указывать "global 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

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

Ответ 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), но, конечно, это много набирает.

Ответ 6

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

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