[Python-es] 'Heredar' un venv dentro de otro

[Kiko]

El 2 de diciembre de 2015, 22:38, Francisco Palm <francisco.palm en gmail.com>
escribió:

>
> Sé que de algún modo ya lo mencionaron antes. Pero considerando que las
> últimas versiones de pip te mantienen un cache de los paquetes que has
> instalado en -cualquier- repositorio de tu equipo, lo que hace falta es un
> gestor de archivos de requerimientos. Que diera la opción de crear
> requerimientos, combinar requerimientos y que en lugar de trabajar con una
> versión específica no requiera ninguna para que tome la mas reciente.
> También un herramienta para configurar fácilmente ese caché en un entorno
> de red para equipos de trabajo (tipo apt-cacher).
>
> Saludos
>

Hola, Francisco.

No entiendo muy bien en qué me puede ayudar la información de la caché. No
tengo problemas en instalar paquetes, tengo problemas en 'trackear' los
dependencias de otros paquetes cuando actualizo una de sus dependencias. La
caché también expira y se actualiza.

Creo que puedo obtener la información de los paquetes que tengo en el venv
hijo (los suyos y los del padre) usando 'pip list'. Lo que tengo que
investigar es como poder actualizar todos los paquetes (en el venv hijo y
que no están en el venv hijo) que dependen de una librería que he
actualizado en el venv hijo y que no haya posibles conflictos con las que
ya hay en el venv padre.

Por ejemplo, si en venv padre he instalado numpy 1.10 y oandas, mpl y
scipy, si instalo numpy 1.9 en el venv hijo sigo pudiendo acceder a pandas,
mpl y scipy pero al importar están rotos porque usan numpy 1.10 y en el
venv hijo el numpy que busca primero es el suyo (1.9) y no el del padre
(1.10). Me gustaría saber que si instalo numpy 1.9, saber qué paquetes del
venv padre hay que usan numpy para poder actualizarlos todos en el hijo
usando numpy 1.9. Este caso de uso es extremo puesto que no quiero resolver
ese problema. Pero es un posible problema que habría que manejar.

No sé si me he explicado mejor o si no te he entendido bien, ya que todo el
tema de packaging es un lío monumental (<sarcasm> No sé porqué </sarcasm).

Saludos.


> F. Palm
>
> El 29 de noviembre de 2015, 3:18 p. m., Kiko<kikocorreoso en gmail.com>
> escribió:
>
>> Hola.
>>
>> No sé si esta será la pregunta rara del día. Ahí va.
>>
>> Imaginad que tengo un venv, llamémosle venv-base, donde tengo instalado
>> cosas que siempre uso (p.e., numpy, scipy, matplotib y pandas) y que suele
>> ser un poco incordio instalar usando pip.
>>
>> ¿Se podría crear un venv que usase estas librerías (las 'heredase' de
>> venv-base) además de las suyas particulares sin tener que instalar numpy,
>> scipy, matplotlib, pandas en el nuevo venv?
>>
>> Algo parecido a la opción --system-site-packages (
>> https://virtualenv.readthedocs.org/en/latest/userguide.html#the-system-site-packages-option
>> )
>>
>> No quiero tener numpy, scipy, matplotlib y Pandas instaladas de base en
>> el sistema pero tampoco quiero tener que instalarlas con cada nuevo venv.
>>
>> Conda/Anaconda ayuda a manejar alguno de los problemas pero, sin tener
>> una burrada de venv's ni de librerías instaladas, tengo carpetas de 6Gb o
>> más.
>>
>> Supongo que lo que quiero no existe y, sin pensar mucho en ello, veo
>> millones de posibles conflictos a manejar.
>>
>> ¿Sería útil que existiera algo así si no existe ya?
>>
>> Gracias.
>>
>> Saludos.
>>
>> _______________________________________________
>> Python-es mailing list
>> Python-es en python.org
>> https://mail.python.org/mailman/listinfo/python-es
>> FAQ: http://python-es-faq.wikidot.com/
>>
>>
>
>
> --
> --------------------------------------
> fpalm en mapologo.org.ve
> francisco.palm en gmail.com
>
> cel: +58 +424 7228252
> tel: +58 +274 6352001
>
> ----
> Debemos ser libres, no para hacer lo que nos plazca, sino libres para
> comprender muy profundamente nuestros propios instintos e impulsos. K
>
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20151203/c0219c94/attachment.html>