python3 - virtualenv python 3 windows
Python virtualenv preguntas (3)
Estoy usando VirtualEnv en Windows XP. Me pregunto si tengo mi cerebro envuelto alrededor de él correctamente.
Corrí virtualenv ENV
y creó C:/WINDOWS/system32/ENV
. Luego cambié mi variable PATH
para incluir C:/WINDOWS/system32/ENV/Scripts
lugar de C:/Python27/Scripts
. Luego verifiqué Django en C:/WINDOWS/system32/ENV/Lib/site-packages/django-trunk
, actualicé mi variable PYTHON_PATH
para que apunte al nuevo directorio de Django, y continué con easy_install
otras cosas (que por supuesto van a mi nuevo directorio C:/WINDOWS/system32/ENV/Lib/site-packages
).
Entiendo por qué debería usar VirtualEnv para poder ejecutar varias versiones de Django y otras bibliotecas en la misma máquina, pero ¿esto significa que para cambiar entre entornos tengo que cambiar básicamente mi PATH
y PYTHON_PATH
? Entonces, ¿paso de desarrollar un proyecto Django que use Django 1.2 en un entorno llamado ENV
y luego cambie mi PATH
y así puedo usar un entorno llamado ENV2
que tenga la versión dev de Django?
¿Es eso básicamente, o hay una mejor manera de hacer todo esto automáticamente (podría actualizar mi ruta en el código Python, pero eso requeriría que escribiera un código específico de la máquina en mi aplicación)?
Además, ¿cómo se compara este proceso con el uso de VirtualEnv en Linux (soy un principiante en Linux)?
Normalmente virtualenv
crea ambientes en el directorio actual. A menos que tenga la intención de crear entornos virtuales en C:/Windows/system32
por alguna razón, usaría un directorio diferente para los entornos.
No debería tener que meterse con las rutas: use el script de activate
(en <env>/Scripts
) para asegurarse de que el ejecutable y la ruta de Python sean específicos del entorno. Una vez que haya hecho esto, el símbolo del sistema cambia para indicar el entorno. Entonces puede simplemente invocar easy_install y todo lo que instale de esta manera se instalará en este entorno. Use deactivate
para volver a configurar todo como estaba antes de la activación.
Ejemplo:
c:/Temp>virtualenv myenv
New python executable in myenv/Scripts/python.exe
Installing setuptools..................done.
c:/Temp>myenv/Scripts/activate
(myenv) C:/Temp>deactivate
C:/Temp>
Tenga en cuenta que no tuve que especificar una ruta para deactivate
: activate
hace por usted, de modo que cuando se active "Python" ejecutará Python en el virtualenv, no en su sistema Python. (Pruébelo: realice un sistema de import sys; sys.prefix
y debería imprimir la raíz de su entorno).
Simplemente puede activar un nuevo entorno para cambiar entre entornos / proyectos, pero deberá especificar la ruta completa para activate
modo que sepa qué entorno activar. Nunca deberías tener que meterte con PATH o PYTHONPATH explícitamente.
Si usa Windows Powershell, puede aprovechar un wrapper . En Linux, el virtualenvwrapper
(el enlace apunta a un puerto de este a Powershell) hace que la vida con virtualenv
sea aún más fácil.
Actualización: No es incorrecto, exactamente, pero quizás no del todo en el espíritu de virtualenv
. Podría usar una táctica diferente: por ejemplo, si instala Django y cualquier otra cosa que necesite para su sitio en su virtualenv, entonces podría trabajar en el directorio de su proyecto (donde está desarrollando su sitio) con el virtualenv activado. Debido a que estaba activado, su Python encontraría Django y cualquier otra cosa que pudiera instalarse fácilmente en el entorno virtual: y como está trabajando en el directorio de su proyecto, los archivos del proyecto también serían visibles para Python.
Actualización adicional: debería poder usar pip
, distribute
lugar de setuptools
, y simplemente python setup.py install
con virtualenv
. Solo asegúrate de haber activado un entorno antes de instalar algo en él.
Sí, básicamente, esto es lo que hace virtualenv, y para esto está el comando de activate
, desde el documento here :
activar script
En un virtualenv recién creado, habrá un bin / activar script de shell, o un archivo por lotes Scripts /ctiv.bat en Windows.
Esto cambiará su $ PATH para que apunte al directorio / virtualenv bin. A diferencia de workingenv, esto es todo lo que hace; es una conveniencia Pero si usa la ruta completa como / ruta / a / env / bin / python script.py, no necesita activar el entorno primero. Tienes que usar la fuente porque cambia el entorno en el lugar. Después de activar un entorno, puede utilizar la función desactivar para deshacer los cambios.
El script de activación también modificará el indicador de la shell para indicar qué entorno está activo actualmente.
así que solo debes usar el comando de activate
que hará todo eso por ti:
> /path/to/env/bin/activate.bat
en mi proyecto, el archivo wsgi.py tengo este código (funciona con virtualenv, django, apache2 en windows y python 3.4)
import os
import sys
DJANGO_PATH = os.path.join(os.path.abspath(os.path.dirname(__file__)),''..'')
sys.path.append(DJANGO_PATH)
sys.path.append(''c:/myproject/env/Scripts'')
sys.path.append(''c:/myproject/env/Lib/site-packages'')
activate_this = ''c:/myproject/env/scripts/activate_this.py''
exec(open(activate_this).read())
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
application = get_wsgi_application()
en el archivo virtualhost conf tengo
<VirtualHost *:80>
ServerName mysite
WSGIScriptAlias / c:/myproject/myproject/myproject/wsgi.py
DocumentRoot c:/myproject/myproject/
<Directory "c:/myproject/myproject/myproject/">
Options +Indexes +FollowSymLinks +MultiViews
AllowOverride All
Require local
</Directory>
</VirtualHost>