Python “isolado” com virtualenv

virtualenv_django

O virtualenv é uma ferramenta que cria um ambiente virtual (dah…), contendo a instância de uma versão específica do Python com seus próprios executável, bibliotecas e e diretório de módulos. O que ele faz é criar “um outro python” isolado daquele que está instalado no sistema e com os ajustes necessários para que ele seja enxergado como o “único” disponível.

Até o pipPython package installer — acredita que aquele é o “python oficial” e fará a instalação de pacotes da linguagem dentro da estrutura dele. Ou seja, é possível criar instâncias tanto com versões distintas da linguagem como também de seus módulos.

Parece complicado de entender? Na prática funciona assim:

$ sudo apt-get install virtualenv
...
$ python --version
Python 2.7.9
$ virtualenv --python=python3 vpy3
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in vpy3/bin/python3
Also creating executable in vpy3/bin/python
Installing setuptools, pip...done.
$ source ./vpy3/bin/activate
(vpy34)$ python --version
Python 3.4.3

O “vpy3” é um nome que eu criei, pode ser qualquer outro nome que te ajude a identificar o ambiente.

A principal vantagem aqui é poder ter um Python “encaixotado”, sem necessariamente se precisar configurar/reconfigurar a todo instante seu sistema para refletir os ajustes dos ambientes de desenvolvimento, testes, homologação, produção etc e como também sem precisar manter uma máquina virtual/contêiner para este fim.

Bem, uma máquina virtual ou um contêiner até pode ser criado para este fim, é algo que dependerá muito do porte da/das aplicação/aplicações que ficará/ficarão por lá. Não encare minha afirmação como uma lei imutável.

Voltando aos teste prático com um exemplo bem simples e bem besta também:

$ mkdir teste
$ cd teste
$ virtualenv --python=python2.7 vpy27
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in vpy27/bin/python2.7
Also creating executable in vpy27/bin/python
Installing setuptools, pip...done.
$ virtualenv --python=python3.4 vpy34
Running virtualenv with interpreter /usr/bin/python3.4
Using base prefix '/usr'
New python executable in vpy34/bin/python3.4
Also creating executable in vpy34/bin/python
Installing setuptools, pip...done.

Criei dois ambientes, um contendo o Python 2.7 e o outro com Python 3.4, claro, ambos já se encontram instalados.

No primeiro instalarei a versão 1.4 do Django:

$ source vpy27/bin/activate
(vpy27)$ pip install django==1.4
Downloading/unpacking django==1.4
  Downloading Django-1.4.tar.gz (7.6MB): 7.6MB downloaded
  Running setup.py (path:/tmp/pip-build-K0sofQ/django/setup.py) egg_info for package django
    
Installing collected packages: django
  Running setup.py install for django
    changing mode of build/scripts-2.7/django-admin.py from 664 to 775
    
    changing mode of /home/giovanni/teste/vpy27/bin/django-admin.py to 775
Successfully installed django
Cleaning up...
(vpy27)$ $ pip list
argparse (1.2.1)
Django (1.4)
pip (1.5.6)
setuptools (12.2)
wsgiref (0.1.2)

E no ambiente com o Python mais novo instalarei (claro) a versão mais recente, a 1.8, mas antes uma última verificação:

(vpy27)$ source ./vpy34/bin/activate
(vpy34)$ pip list
pip (1.5.6)
setuptools (12.2)

Onde foi parar o Django? Simples, aqui ele não está instalado, portanto:

(vpy34)$ pip install django==1.8
Downloading/unpacking django==1.8
  Downloading Django-1.8-py2.py3-none-any.whl (6.2MB): 6.2MB downloaded
Installing collected packages: django
Successfully installed django
Cleaning up...
(vpy34)$ pip list
Django (1.8)
pip (1.5.6)
setuptools (12.2)
(vpy34)$

E como sei que isto funciona? Hora de fazer (mais) um teste.

Um aviso, a função aqui é apenas de demonstrar o virtualenv em ação, sei que há pequenas diferenças de sintaxe entre as versões do 2.x e 3.x do Python, assim como diferenças de procedimentos nas versões 1.4 e 1.8 do próprio Django. Logo não irei fazer nada mais complicado do que levantar o servidor web.

Usando o ambiente com versões mais antigas criei um projeto no Django:

(vpy27)$ django-admin startproject teste1 .

E em consoles diferentes subi o servidor web nas duas versões do framework (obviamente em portas TCP distintas), primeiro para o Django 1.4:

(vpy27)$ ./manage.py runserver 127.0.0.1:8027

E depois para o Django 1.8:

(vpy34)$ ./manage.py runserver 127.0.0.1:8034

E o resultado…

virtualenv_django_firefoxes

Como disse, é um teste besta, mas isto aqui também poderia seria algo como o início de processo de atualização de aplicação. Aliás, usei o mesmo projeto nas duas versões o que em si não parece lá uma boa ideia mas, como estou enfatizando, é um teste besta. 🙂

E, finalizando, há implementações do virtualenv para Perl, eu contei umas três delas mas ainda não tive tempo de testá-las com calma, quando conseguir publico o resultado por aqui.

Anúncios

4 comentários sobre “Python “isolado” com virtualenv

  1. Pingback: Instalando o MacPorts | giovannireisnunes

  2. Pingback: Aplicação web em Python e Bottle – parte 1 | giovannireisnunes

  3. Boa noite amigos,

    Como faço para listar os virtualenvs criados…. existe algum comando que façao isso?

    eu to tentando ilistar usando esse comando “lsvirtualenv -b “, más não está retornando nada.

    Desde já agradeço.

    Curtir

    • O lsvirtualenv faz parte de um outro programa, o virtualenvwrapper. Você tem ele instalado? Uma forma de listar todos os ambientes virtuais definidos a partir de um diretório específico é find . -name 'activate_this.py' -exec dirname '{}' \;

      Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s