tema django-admin.py y virtualenv en Windows

Question

En mi sistema no es Django 1.2.3 sistema instalado amplia:

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

Entonces hay un entorno virtual llamada Venv en C: \ dev donde 1.2.4 instalado Django:

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 

Mis preguntas:

1. re Por qué django-admin.py puertos versión 1.2.3, si el entorno Python (virtual) actual tiene instalado django 1.2.4?
2. ¿Cómo puedo usar Django's 1.2.4 django-admin.py automáticamente cuando venv está activo?

Otros detalles:

• virtualenv versión: 1.5.1, Python versión 2.7
• comando utilizado para crear Venv: C:\dev\> virtualenv --no-site-packages venv

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

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

• tinglado de django-admin.py en Venv: #!C:\dev\Scripts\python.exe

espera que usted pueda ayudar, muchas gracias.

Answer 1

Esto se debe a que su Windows tiene asociada la extensión .py con la python.exe instalada a nivel mundial.Por lo tanto, cuando escribe django-admin.py, aunque se encuentre en una virtualidad, se invoca la python global, que a su vez encuentra su instalación global de django en sus propios paquetes de sitio. Pruebe python django-admin.py para eludir la asociación.

Answer 2

tuve un problema similar en Linux cuando traté de usar una ya exisiting proyecto Django con un instalado tarde virtualenv.

¿Es posible que django-admin.py de django 1.2.4 sea no en su ruta pero que django-admin.py de su instalación de django 1.2.3 es?

que explicaría su salida de

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 

porque el comando python está en el camino de su virtualenv pero el archivo django-admin.py podría no ser.

En cuanto a su segunda pregunta (asumiendo que mi suposición anterior es correcta): sym-link el archivo django-admin.py en su directorio C:\dev\venv\Scripts, aunque no estoy seguro de cómo funciona en Windows (¿está usando Cygwin?).

Por supuesto, siempre se puede llamar como python C:\path\to\django-admin.py (ya que se llama a la versión de python correcta), pero por supuesto que es una gran cantidad de tipeo.

Answer 3

Como ya explicó shanyu, es debido a las asociaciones de archivos * .py realizadas en el ejecutable de instalación de Python en lugar de su virtualenv. Sin embargo, para responder a su segunda pregunta de manera diferente, resolví este problema creando un django-admin.bat en el directorio Scripts de mi virtualenv. ¿Su contenido?

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

Ahora puede usar django-admin startproject <project_name>. Las variables de entorno necesarias PATH y VIRTUAL_ENV ya deberían haber sido configuradas correctamente por virtualenv cuando activó el entorno.

Answer 4

i utilizado solución de Philip Nelson, pero tuvo que añadir las citas para los espacios en mi nombre:

pitón "% VIRTUAL_ENV% \ Scripts \ django-admin.py" % *

Answer 5

me acaba de escribir django- admin, sin la extensión de archivo .py, y funcionó para mí.

Answer 6

tuviera que señalar la "python.exe global" a mi virtualenv en mi proyecto así que creé mi propia activate.cmd

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

Cambia la asociación de tipo de archivo usando el comando de las ventanas 'ftype'.