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

Kiko kikocorreoso en gmail.com
Lun Nov 30 08:04:36 EST 2015


El 30 de noviembre de 2015, 13:29, Chema Cortes <pych3m4 en gmail.com>
escribió:

>
>
> El lun., 30 nov. 2015 a las 11:44, monoBOT (<monobot.soft en gmail.com>)
> escribió:
>
>> Pues es cierto que puede ser un proyecto interesante.
>>
>> Ahora mismo lo único que se me ocurre es que copies los entornos y luego
>> a mano borrar y crear enlaces simbólicos a los diferentes repositorios
>> (para evitar gasto de HD innecesaria) y para instalaciones que no quieras
>> propagar habría que borrar el enlace.
>> Lo malo de ésta técnica es que dependiendo del nivel de complejidad al
>> final es inmantenible ... no sabrás donde estas en cada uno de los entornos
>> y que herramientas son instaladas o enlazadas.
>>
>> .env/entornobase/rep1
>>                .../rep2
>>                .../rep3
>>
>> .env/entorno2(enlazado a base)/(ln to rep1)
>>                  .../(ln to rep2)
>>                  .../rep4
>>                  .../rep5
>>
>> .envs/entorno3(enlazado a 2)/(ln to rep2)
>>                  .../(ln to rep2)
>>                  .../(ln to rep4)
>>                  .../(ln to rep5)
>>
>>
>
> Podría ser problemático ejecutar scripts de un virtualenv como subproceso
> de otro virtualenv. La idea de tener virtualenvs es justamente aislar los
> entornos de ejecución del resto de cambios en la configuración de paquetes.
>
> Pero entiendo que lo que se quiere es tan sólo reusar los paquetes
> instalados de un entorno, no los ejecutables. Para ello siempre se puede
> tener un fichero .pth con las rutas a los directorios de paquetes de los
> otros entornos. Algo que facilita mantener envplus:
> https://github.com/jsvine/envplus
>
>
@monobot he experimentado esa vía y no es simple hacerlo a mano. Si hay una
solución adhoc testada sería lo deseable. Gracias.

@chema: ups, esto quizá sea lo que andaba buscando. En cuanto me dejen un
rato lo pruebo y doy feedback por si a alguien le pudiera interesar.
Gracias.


>
>
>> El 30 de noviembre de 2015, 7:31, Kiko <kikocorreoso en gmail.com> escribió:
>>
>>>
>>>
>>> El 30 de noviembre de 2015, 1:01, Mario R. Osorio <
>>> mario en osorio.solutions> escribió:
>>>
>>>> Yo creo que lo mas conveniente y seguro es crear un archivo de
>>>> requerimientos con tus requerimientos basicos...
>>>>
>>>
>>> Gracias, Mario.
>>>
>>> Esa solución ya existe y no me soluciona el problema puntual de tener
>>> entornos ligeros y ágiles basados en otros más pesados y duraderos.
>>>
>>>
>>>>
>>>>
>>>> Dtb/Gby
>>>> =======
>>>> Mario R. Osorio
>>>> A.S. of Computer Programming and Analysis
>>>>
>>>> “If I had asked people what they wanted, they would have said faster
>>>> horses.”
>>>>  ― Henry Ford
>>>>
>>>>
>>>>
>>>> 2015-11-29 14:48 GMT-05:00 Kiko <kikocorreoso en gmail.com>:
>>>>
>>>>> 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/
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Python-es mailing list
>>>> Python-es en python.org
>>>> https://mail.python.org/mailman/listinfo/python-es
>>>> FAQ: http://python-es-faq.wikidot.com/
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Python-es mailing list
>>> Python-es en python.org
>>> https://mail.python.org/mailman/listinfo/python-es
>>> FAQ: http://python-es-faq.wikidot.com/
>>>
>>>
>>
>>
>> --
>> *monoBOT*
>> Visite mi sitio(Visit my site): monobotsoft.es/blog/
>> _______________________________________________
>> Python-es mailing list
>> Python-es en 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://ch3m4.org/blog
>
> _______________________________________________
> 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/20151130/8956c273/attachment.html>


Más información sobre la lista de distribución Python-es