[Python-es] Virtualenv proyecto limpio

2016-09-30 Por tema kausdiv

  
  
Hola a todos.
Por comodidad (lo reconozco), en python tengo instalado lo que
  más uso: PyQt, SQLAlchemy, numpy y poco más.
Ahora haciendo un curso de Django, quiero crear una
  virtualización, pero a ser posible limpia.
Es decir que no me arrastre (PyQt... etc).
He probado:
virtualenv --no-site-packages
  prueba
al activarlo y hacer pip freeze sigue estando todos los paquetes
  anteriores.
¿ Sabéis si se puede hacer lo que digo ? 

Que se instale con lo necesario de python nada más.


Saludos.




  

___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] Virtualenv proyecto limpio

2016-09-30 Por tema Daπid
Pregunta tonta: has activado el virtualenv antes de ejecutar pip freeze?

On 30 Sep 2016 10:10, "kausdiv"  wrote:

> Hola a todos.
>
> Por comodidad (lo reconozco), en python tengo instalado lo que más uso:
> PyQt, SQLAlchemy, numpy y poco más.
>
> Ahora haciendo un curso de Django, quiero crear una virtualización, pero a
> ser posible limpia.
>
> Es decir que no me arrastre (PyQt... etc).
>
> He probado:
>
> virtualenv --no-site-packages prueba
>
> al activarlo y hacer pip freeze sigue estando todos los paquetes
> anteriores.
>
> ¿ Sabéis si se puede hacer lo que digo ?
>
> Que se instale con lo necesario de python nada más.
>
>
> Saludos.
>
>
>
>
> ___
> Python-es mailing list
> Python-es@python.org
> https://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
>
___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] De paquetes y de huevos

2016-09-30 Por tema Antonio Beamud Montero

El 29/09/16 a las 22:09, Mario Lacunza escribió:
Una pregunta de donde sacas este argumento? ese mas parece el manejo 
de Windows y no de Linux.


¿A que argumento te refieres?


Cuando un paquete A necesita la lib1.2 la instala (si esta disponible 
en el repositorio) Sino la compilas.


Si en el OS está ya instalada la lib1.3 esta sigue funcionando y los 
programas q la necesiten seguiran apuntando a ella y no a lib1.2 
(precisamente el DLL Hell de windows)





AHORA si te refieres a UNICAMENTE a subprogramas de o para python 
entonces usas el virutalenv y listo. Cuál es el drama?

Todo me refiero a librerias y programas de python.
Intento evitar todo eso, mezclar paquetes/librerías instaladas via 
apt-get y las instaladas via pip.
Imagina que la distribución instala via apt-get un paquete paqX, que 
depende de la librería >=lib1.3. Tu ahora instalas tu egg que depende de 
la librería lib2.9 (que hace cambios en el api de la lib), esa 
aplicación paqX te puede empezar a dar problemas, porque resuelve 
dependencias contra la lib2.9 (incluso peores casos donde no se 
especifica en los requerimientos que versión necesita para funcionar).
Esto es precisamente lo que intento evitar, y lo que me gustaría es 
poder simular todas las dependencias que tienen una distribución, y 
poder probar paquetes que no están en la distribución para ver que 
resuelve bien dependencias y no genera conflictos.


No hay ningún drama, la idea final es que intento no mezclar paquetes 
instalados con apt-get y con pip, porque al final, lo que quiero es 
poder crear paquetes para las distribuciones que se instalen via 
apt-get, pero antes quiero probar todo en un entorno ligero via 
virtualenv. (no se si me explico).


Para eso necesitaría meter las mismas versiones que llevan las distintas 
distribuciones, y poder crear un virtualenv ubuntu12.04 (por ejemplo), 
instalando ahí con pip las mismas versiones que se instalan via apt-get 
en ubuntu 12.04...



Saludos / Best regards

Mario Lacunza
Email:: mlacu...@gmail.com 
Personal Website:: http://www.lacunza.biz/
Hosting:: http://mlv-host.com/
Skype: mlacunzav

Lima - Peru

El 29 de septiembre de 2016, 08:33, Antonio Beamud 
Monteromailto:antonio.bea...@gmail.com>> 
escribió:


Como ya sabéis las distribuciones de linux empaquetan una serie de
librerías y utilidades de python en una versión concreta. Cuando
desarrollas algo sobre python, y necesitas alguna librería que no
está disponible en paquete para tu distribución, normalmente tiras
de huevos (que mal suena eso :D) y lo instalas vía
pip/easy_install... Esto lleva a que si no tienes cuidado, esa
nueva librería que instalas, puede tirar de dependencias y
actualizar alguna de las librerías que ya tenías previamente
instaladas vía sistema de paquetes, pudiendo provocar
mal-funcionamientos en otras aplicaciones como efecto colateral.



___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/



___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] Virtualenv proyecto limpio

2016-09-30 Por tema kausdiv

  
  
Si.
  
  Por si acaso, lo acabo de hacer:
  
  
  Saludos.
  
  El 30/09/2016 a las 10:21, Daπid escribió:


  Pregunta tonta: has activado el virtualenv antes de
ejecutar pip freeze? 
  
On 30 Sep 2016 10:10, "kausdiv" 
  wrote:
  

  Hola a todos.
  Por comodidad (lo reconozco), en python tengo instalado
lo que más uso: PyQt, SQLAlchemy, numpy y poco más.
  Ahora haciendo un curso de Django, quiero crear una
virtualización, pero a ser posible limpia.
  Es decir que no me arrastre (PyQt... etc).
  He probado:
  virtualenv --no-site-packages
prueba
  al activarlo y hacer pip freeze sigue estando todos los
paquetes anteriores.
  ¿ Sabéis si se puede hacer lo que digo ? 
  
  Que se instale con lo necesario de python nada más.
  
  
  Saludos.
  
  
  
  


___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/

  

  
  
  
  
  ___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/




  

___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] De paquetes y de huevos

2016-09-30 Por tema Chema Cortes
El vie., 30 sept. 2016 a las 10:53, Antonio Beamud Montero (<
antonio.bea...@gmail.com>) escribió:

>
> Intento evitar todo eso, mezclar paquetes/librerías instaladas via apt-get
> y las instaladas via pip.
> Imagina que la distribución instala via apt-get un paquete paqX, que
> depende de la librería >=lib1.3. Tu ahora instalas tu egg que depende de la
> librería lib2.9 (que hace cambios en el api de la lib), esa aplicación paqX
> te puede empezar a dar problemas, porque resuelve dependencias contra la
> lib2.9 (incluso peores casos donde no se especifica en los requerimientos
> que versión necesita para funcionar).
> Esto es precisamente lo que intento evitar, y lo que me gustaría es poder
> simular todas las dependencias que tienen una distribución, y poder probar
> paquetes que no están en la distribución para ver que resuelve bien
> dependencias y no genera conflictos.
>
> No hay ningún drama, la idea final es que intento no mezclar paquetes
> instalados con apt-get y con pip, porque al final, lo que quiero es poder
> crear paquetes para las distribuciones que se instalen via apt-get, pero
> antes quiero probar todo en un entorno ligero via virtualenv. (no se si me
> explico).
>
> Para eso necesitaría meter las mismas versiones que llevan las distintas
> distribuciones, y poder crear un virtualenv ubuntu12.04 (por ejemplo),
> instalando ahí con pip las mismas versiones que se instalan via apt-get en
> ubuntu 12.04...
>
>
Si entiendo bien, pretendes mantener versiones distintas según las
distintas distribuciones de linux. Es completamente una locura. Si ya es
complicado mantener versiones para distintas plataformas, ampliar el
espectro a todas las posibles configuraciones es imposible. Por lo menos
tendrás versiones distintas para python2 y python3, además de versiones
diferentes de otras librerías principales (gtk2/gtk3, qt4/qt5,
mysql/mariadb,).

Este problema es común a todos los lenguajes de programación y la solución
es docker. No sé porqué lo has descartado tan pronto. Si no te parece
liviano coreOS o rancherOS, es que no tenemos el mismo concepto de
"liviano". Hoy en día, incluso se puede asociar la ejecución de un
contendor docker con la carga de un módulo python, similar a lo que sería
la carga de una librería dinámica, pero sin los problemas de dependencias
con librerías del sistema. Por ahí va el futuro de python y de muchos otros
lenguajes, aunque no sabría decirte si será docker, rkt u otro mejor.
-- 
Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
http://blog.ch3m4.org 
___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] De paquetes y de huevos

2016-09-30 Por tema Antonio Beamud Montero

El 30/09/16 a las 11:49, Chema Cortes escribió:
El vie., 30 sept. 2016 a las 10:53, Antonio Beamud Montero 
(mailto:antonio.bea...@gmail.com>>) escribió:




Para eso necesitaría meter las mismas versiones que llevan las
distintas distribuciones, y poder crear un virtualenv ubuntu12.04
(por ejemplo), instalando ahí con pip las mismas versiones que se
instalan via apt-get en ubuntu 12.04...


Si entiendo bien, pretendes mantener versiones distintas según las 
distintas distribuciones de linux. Es completamente una locura. Si ya 
es complicado mantener versiones para distintas plataformas, ampliar 
el espectro a todas las posibles configuraciones es imposible. Por lo 
menos tendrás versiones distintas para python2 y python3, además de 
versiones diferentes de otras librerías principales (gtk2/gtk3, 
qt4/qt5, mysql/mariadb,).


Si, bueno, no para todas las distros de linux, solo 2 o 3, realmente 
poder ir probando posibles migraciones.
Tengo experiencia en la pesadilla que supone mantener para varias 
distros, pero es impepinable por ahora...




Este problema es común a todos los lenguajes de programación y la 
solución es docker. No sé porqué lo has descartado tan pronto. Si no 
te parece liviano coreOS o rancherOS, es que no tenemos el mismo 
concepto de "liviano". Hoy en día, incluso se puede asociar la 
ejecución de un contendor docker con la carga de un módulo python, 
similar a lo que sería la carga de una librería dinámica, pero sin los 
problemas de dependencias con librerías del sistema. Por ahí va el 
futuro de python y de muchos otros lenguajes, aunque no sabría decirte 
si será docker, rkt u otro mejor.


Descarté máquinas virtuales y docker en su día, porque tengo mucha 
dependencia de la GPU (a través de opencl). En máquinas virtuales he 
tenido muchos problemas cuando he probado (todo muy experimental), y 
medir los tiempos necesito que todo sea cuando más cercano al metal 
mejor... Repecto a docker, lo desestime por la experiencia con las 
máquinas virtuales...


La conclusión a la que he llegado, es que lo más sencillo en mi caso 
sería, poder generar un virtualenv, con una plantilla de los paquetes 
que incluye una distribución en concreta, meter mi soft, lanzar los 
tests y ver donde da problemas. Si puedo adaptarlo para que funcione sin 
problemas en varias distros sin necesidades especiales, mejor, e 
intentar generar paquetes para esa distro... El único coñazo es tener 
que instalar la distro (o buscar el listado de paquetes en la web), 
sacar los de python de los que dependo, sus versiones y crear el 
virtualenv con él... Sino darle la oportunidad a docker, para 
distribuirlo...


Un saludo.



--
Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales": 
http://blog.ch3m4.org 



___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/



___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] De paquetes y de huevos

2016-09-30 Por tema Chema Cortes
El vie., 30 sept. 2016 a las 12:29, Antonio Beamud Montero (<
antonio.bea...@gmail.com>) escribió:

> El 30/09/16 a las 11:49, Chema Cortes escribió:
>
> El vie., 30 sept. 2016 a las 10:53, Antonio Beamud Montero (<
> antonio.bea...@gmail.com>) escribió:
>
>
>>
>> Para eso necesitaría meter las mismas versiones que llevan las distintas
>> distribuciones, y poder crear un virtualenv ubuntu12.04 (por ejemplo),
>> instalando ahí con pip las mismas versiones que se instalan via apt-get en
>> ubuntu 12.04...
>>
>>
> Si entiendo bien, pretendes mantener versiones distintas según las
> distintas distribuciones de linux. Es completamente una locura. Si ya es
> complicado mantener versiones para distintas plataformas, ampliar el
> espectro a todas las posibles configuraciones es imposible. Por lo menos
> tendrás versiones distintas para python2 y python3, además de versiones
> diferentes de otras librerías principales (gtk2/gtk3, qt4/qt5,
> mysql/mariadb,).
>
>
> Si, bueno, no para todas las distros de linux, solo 2 o 3, realmente poder
> ir probando posibles migraciones.
> Tengo experiencia en la pesadilla que supone mantener para varias distros,
> pero es impepinable por ahora...
>
>
>
> Este problema es común a todos los lenguajes de programación y la solución
> es docker. No sé porqué lo has descartado tan pronto. Si no te parece
> liviano coreOS o rancherOS, es que no tenemos el mismo concepto de
> "liviano". Hoy en día, incluso se puede asociar la ejecución de un
> contendor docker con la carga de un módulo python, similar a lo que sería
> la carga de una librería dinámica, pero sin los problemas de dependencias
> con librerías del sistema. Por ahí va el futuro de python y de muchos otros
> lenguajes, aunque no sabría decirte si será docker, rkt u otro mejor.
>
>
> Descarté máquinas virtuales y docker en su día, porque tengo mucha
> dependencia de la GPU (a través de opencl). En máquinas virtuales he tenido
> muchos problemas cuando he probado (todo muy experimental), y medir los
> tiempos necesito que todo sea cuando más cercano al metal mejor... Repecto
> a docker, lo desestime por la experiencia con las máquinas virtuales...
>
>
Aunque a veces van asociados, docker no es una máquina virtual. La
confusión viene de que docker corre nativamente en linux (de 64 bits), por
lo que se necesitan máquinas virtuales en mac y windows. Pero si trabajas
en linux, no necesitas virtualizar nada, tan sólo lanzar docker como
servicio (y con rkt ni eso).

Cuando usas virtualenv, juegas con el PATH del entorno para posicionar unas
versiones de módulos sobre otras; con docker, juegas con el sistema de
ficheros BTRFS para posicionar unos directorios por encima de otros. Si
buscas algo más cercano al metal, docker parece mejor preparado que
virtualenv.


>
> La conclusión a la que he llegado, es que lo más sencillo en mi caso
> sería, poder generar un virtualenv, con una plantilla de los paquetes que
> incluye una distribución en concreta, meter mi soft, lanzar los tests y ver
> donde da problemas. Si puedo adaptarlo para que funcione sin problemas en
> varias distros sin necesidades especiales, mejor, e intentar generar
> paquetes para esa distro... El único coñazo es tener que instalar la distro
> (o buscar el listado de paquetes en la web), sacar los de python de los que
> dependo, sus versiones y crear el virtualenv con él... Sino darle la
> oportunidad a docker, para distribuirlo...
>

Mi recomendación es que te lo hagas tú. Instala distintas distribuciones,
instalas las dependencias que necesitas y genera el listado de
dependencias. Con conda, es bastante sencillo generar los listados de
dependencias y clonar entornos virtuales.


>
> Un saludo.
>
>
> --
> Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
> http://blog.ch3m4.org 
>
>
> ___
> Python-es mailing 
> listPython-es@python.orghttps://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
> ___
> Python-es mailing list
> Python-es@python.org
> https://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
-- 
Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
http://blog.ch3m4.org 
___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] De paquetes y de huevos

2016-09-30 Por tema Antonio Beamud Montero

El 30/09/16 a las 13:31, Chema Cortes escribió:



Descarté máquinas virtuales y docker en su día, porque tengo mucha
dependencia de la GPU (a través de opencl). En máquinas virtuales
he tenido muchos problemas cuando he probado (todo muy
experimental), y medir los tiempos necesito que todo sea cuando
más cercano al metal mejor... Repecto a docker, lo desestime por
la experiencia con las máquinas virtuales...


Aunque a veces van asociados, docker no es una máquina virtual. La 
confusión viene de que docker corre nativamente en linux (de 64 bits), 
por lo que se necesitan máquinas virtuales en mac y windows. Pero si 
trabajas en linux, no necesitas virtualizar nada, tan sólo lanzar 
docker como servicio (y con rkt ni eso).


Cuando usas virtualenv, juegas con el PATH del entorno para posicionar 
unas versiones de módulos sobre otras; con docker, juegas con el 
sistema de ficheros BTRFS para posicionar unos directorios por encima 
de otros. Si buscas algo más cercano al metal, docker parece mejor 
preparado que virtualenv.




Si, si estuve investigando y leyendo sobre lo de usar lxc, etc.. pero 
estuve leyendo de gente que le había dado problemas, y como venía de 
hacer tantas pruebas infructuosas con las máquinas virtuales, por eso lo 
dejé en vía muerta... puede que tengas razón y tenga que probar más 
sobre docker... pero por ahora me decanto por montar la infraestructura 
con virtualenvs emulando las distros.


P.D: Me apunto lo de conda para usarlo.

Gracias a todos por vuestros aportes.

Un cordial saludo.

___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] Virtualenv proyecto limpio

2016-09-30 Por tema Ricardo Cárdenes
Basado en algo que he visto en StackOverflow... ¿Qué te responde esto?:

  $ which pip

Debería ser el pip instalado en tu virtualenv, pero asegúrate. Si se está
usando el global, entonces de poco te vale.

2016-09-29 23:42 GMT-10:00 kausdiv :

> Si.
>
> Por si acaso, lo acabo de hacer:
>
>
> Saludos.
>
>
> El 30/09/2016 a las 10:21, Daπid escribió:
>
> Pregunta tonta: has activado el virtualenv antes de ejecutar pip freeze?
>
> On 30 Sep 2016 10:10, "kausdiv"  wrote:
>
>> Hola a todos.
>>
>> Por comodidad (lo reconozco), en python tengo instalado lo que más uso:
>> PyQt, SQLAlchemy, numpy y poco más.
>>
>> Ahora haciendo un curso de Django, quiero crear una virtualización, pero
>> a ser posible limpia.
>>
>> Es decir que no me arrastre (PyQt... etc).
>>
>> He probado:
>>
>> virtualenv --no-site-packages prueba
>>
>> al activarlo y hacer pip freeze sigue estando todos los paquetes
>> anteriores.
>>
>> ¿ Sabéis si se puede hacer lo que digo ?
>>
>> Que se instale con lo necesario de python nada más.
>>
>>
>> Saludos.
>>
>>
>>
>>
>> ___
>> Python-es mailing list
>> Python-es@python.org
>> https://mail.python.org/mailman/listinfo/python-es
>> FAQ: http://python-es-faq.wikidot.com/
>>
>>
>
> ___
> Python-es mailing 
> listPython-es@python.orghttps://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
>
>
> ___
> Python-es mailing list
> Python-es@python.org
> https://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
>
___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/


Re: [Python-es] Virtualenv proyecto limpio

2016-09-30 Por tema Ricardo Cárdenes
También, asegúrate de que tu PYTHONPATH no contiene cosas adicionales.

2016-09-30 18:32 GMT-10:00 Ricardo Cárdenes :

> Basado en algo que he visto en StackOverflow... ¿Qué te responde esto?:
>
>   $ which pip
>
> Debería ser el pip instalado en tu virtualenv, pero asegúrate. Si se está
> usando el global, entonces de poco te vale.
>
> 2016-09-29 23:42 GMT-10:00 kausdiv :
>
>> Si.
>>
>> Por si acaso, lo acabo de hacer:
>>
>>
>> Saludos.
>>
>>
>> El 30/09/2016 a las 10:21, Daπid escribió:
>>
>> Pregunta tonta: has activado el virtualenv antes de ejecutar pip freeze?
>>
>> On 30 Sep 2016 10:10, "kausdiv"  wrote:
>>
>>> Hola a todos.
>>>
>>> Por comodidad (lo reconozco), en python tengo instalado lo que más uso:
>>> PyQt, SQLAlchemy, numpy y poco más.
>>>
>>> Ahora haciendo un curso de Django, quiero crear una virtualización, pero
>>> a ser posible limpia.
>>>
>>> Es decir que no me arrastre (PyQt... etc).
>>>
>>> He probado:
>>>
>>> virtualenv --no-site-packages prueba
>>>
>>> al activarlo y hacer pip freeze sigue estando todos los paquetes
>>> anteriores.
>>>
>>> ¿ Sabéis si se puede hacer lo que digo ?
>>>
>>> Que se instale con lo necesario de python nada más.
>>>
>>>
>>> Saludos.
>>>
>>>
>>>
>>>
>>> ___
>>> Python-es mailing list
>>> Python-es@python.org
>>> https://mail.python.org/mailman/listinfo/python-es
>>> FAQ: http://python-es-faq.wikidot.com/
>>>
>>>
>>
>> ___
>> Python-es mailing 
>> listPython-es@python.orghttps://mail.python.org/mailman/listinfo/python-es
>> FAQ: http://python-es-faq.wikidot.com/
>>
>>
>>
>> ___
>> Python-es mailing list
>> Python-es@python.org
>> https://mail.python.org/mailman/listinfo/python-es
>> FAQ: http://python-es-faq.wikidot.com/
>>
>>
>
___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/