problema django-admin.py e virtualenv su Windows

Question

Nel mio sistema c'è Django 1.2.3 sistema installato un'ampia:

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

Poi c'è un ambiente virtuale chiamato venv in C: \ dev dove ho installati 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 

Le mie domande:

1. Perché django-admin.py re porte versione 1.2.3, se l'attuale ambiente Python (virtuale) ha installato django 1.2.4?
2. Come posso utilizzare Django 1.2.4 django-admin.py automaticamente quando venv è attivo?

Ulteriori informazioni:

• virtualenv versione: 1.5.1, versione di Python 2.7
• comando utilizzato per creare venv: C:\dev\> virtualenv --no-site-packages venv

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

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

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

spera che possiate aiutare, molte grazie.

Answer 1

Questo perché la tua finestra ha associato l'estensione .py con il python.exe installato a livello globale.Pertanto, quando si digita django-admin.py, anche se si è in una virtualenv, viene richiamato il Python globale, che a sua volta trova l'installazione di django globale nei propri pacchetti del sito. Prova python django-admin.py per aggirare l'associazione.

Answer 2

Ho avuto un problema simile su linux quando ho cercato di utilizzare un già exisiting progetto Django con una successiva installato virtualenv.

È possibile che django-admin.py di Django 1.2.4 è non sul vostro percorso, ma che django-admin.py della vostra django 1.2.3 installazione è?

Questo spiegherebbe la vostra uscita da

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 

perché il comando python si trova sul percorso del vostro virtualenv ma il file django-admin.py potrebbe non essere.

Per quanto riguarda la seconda domanda (supponendo che la mia ipotesi sopra sia corretta): sym-link il file django-admin.py nella directory C:\dev\venv\Scripts, anche se non sono sicuro di come funzioni su Windows (stai usando Cygwin?).

Ovviamente si può sempre chiamarlo come python C:\path\to\django-admin.py (dal momento che viene chiamata la versione corretta di Python) ma, naturalmente, questo è un sacco di digitazione.

Answer 3

Come shanyu ha già spiegato, è a causa delle associazioni di file * .py apportate al tuo eseguibile di installazione Python invece che al virtualenv. Tuttavia, per rispondere alla tua seconda domanda in modo diverso, ho risolto questo problema creando un django-admin.bat nella directory Scripts del mio virtualenv. I suoi contenuti?

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

Ora è possibile utilizzare django-admin startproject <project_name>. Le necessarie variabili di ambientedevono essere già state impostate correttamente da virtualenv quando si è attivato l'ambiente.

Answer 4

ho usato la soluzione di Philip Nelson, ma dovuto aggiungere le citazioni per gli spazi nel mio nome:

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

Answer 5

ho scritto django- admin, senza l'estensione di file .py, e ha funzionato per me.

Answer 6

ho dovuto puntare il "python.exe globale" alla mia virtualenv nel mio progetto così ho creato il mio 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 l'associazione tipo di file utilizzando Windows comando 'ftype'.