setup python3 making how activate activar python windows linux virtualenv

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>