¿Tiene sentido usar Conda + Poesía?

8 minutos de lectura

Avatar de usuario de Seub
Seub

¿Tiene sentido usar Conda + Poetry para un proyecto de Machine Learning? Permítame compartir mi comprensión (novata) y corríjame o ilumíneme:

Hasta donde yo entiendo, Conda y Poesía tienen diferentes propósitos pero son en gran parte redundantes:

  • Conda es principalmente un administrador de entornos (de hecho, no necesariamente Python), pero también puede administrar paquetes y dependencias.
  • Poetry es principalmente un administrador de paquetes de Python (digamos, una actualización de pepita), pero también puede crear y administrar entornos de Python (por ejemplo, una actualización de Pyenv).

Mi idea es usar ambos y compartimentar sus roles: dejar que Conda sea el administrador del entorno y Poetry el administrador de paquetes. Mi razonamiento es que (parece que) Conda es mejor para administrar entornos y puede usarse para compilar e instalar paquetes que no sean de Python, especialmente controladores CUDA (para capacidad de GPU), mientras que Poetry es más poderoso que Conda como administrador de paquetes de Python.

Me las arreglé para hacer que esto funcione con bastante facilidad usando Poetry dentro de un entorno Conda. El truco es no usar Poetry para administrar el entorno de Python: no estoy usando comandos como poetry shell o poetry runsolamente poetry init, poetry install etc (después de activar el entorno Conda).

Para una divulgación completa, mi entorno.yml archivo (para Conda) se ve así:

name: N

channels:
  - defaults
  - conda-forge

dependencies:
  - python=3.9
  - cudatoolkit
  - cudnn

y mi poesia.toml archivo se ve así:

[tool.poetry]
name = "N"
authors = ["B"]

[tool.poetry.dependencies]
python = "3.9"
torch = "^1.10.1"

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

Para ser honesto, una de las razones por las que procedí de esta manera es que estaba luchando por instalar CUDA (para compatibilidad con GPU) sin Conda.

¿Le parece razonable el diseño de este proyecto?

  • Solo por su descripción, suena demasiado complicado. ¿Hay algo que necesites de la poesía que te apetezca conda y pip no son capaces de proporcionar para usted

    – FlyingTeller

    25 de enero a las 15:56

  • Parece un poco propenso a la opinión como pregunta (¿quizás mejor para reddit?), Pero en general parece estar bien. Con suerte, algunos usuarios de poesía pesados ​​​​pueden opinar, pero en el lado de Conda no parece que haya ninguna señal de alerta.

    – merv

    25 de enero a las 16:15

  • @FlyingTeller Puede que tengas razón. En mi situación, solo pienso en Poetry como una actualización de pip: es más potente, facilita el seguimiento de las dependencias y guarda una configuración. Conda también puede hacer eso, pero no tan bien como Poesía (tal vez). Pero sí, la desventaja es que tengo que hacer malabarismos con Conda + Poesía. Aunque puedo escribir un script para automatizar eso.

    – Seub

    25 de enero a las 16:41


  • @Seub He estado usando una configuración de Conda + Poetry muy similar durante el último año y ha funcionado bien.

    – michau

    13 de febrero a las 20:47

  • Estoy más o menos en el mismo bote. Prefiero poesía para la gestión de paquetes, pero instalar CUDA en un clúster HPC sin acceso a sudo no es bueno para mi salud.

    – post meridiano zonificado

    17 de febrero a las 23:46

avatar de usuario de michau
michau

Tengo experiencia con una configuración de Conda + Poetry y ha funcionado bien. La gran mayoría de mis dependencias se especifican en pyproject.tomlpero cuando hay algo que no está disponible en PyPI, o instalarlo con Conda es más fácil, lo agrego a environment.yml. Además, Conda se utiliza como administrador de entornos virtuales, lo que funciona bien con Poetry: no es necesario utilizar poetry run o poetry shellbasta con activar el entorno Conda adecuado.

Consejos para crear un entorno reproducible

  1. Agregue Poesía, posiblemente con un número de versión (si es necesario), como una dependencia en environment.ymlpara que tengas Poetry instalado cuando ejecutes conda createjunto con Python y otras dependencias que no son PyPI.
  2. Agregar conda-lockque le brinda archivos de bloqueo para las dependencias de Conda, tal como lo ha hecho poetry.lock para las dependencias de Poesía.
  3. Considere usar mamba que generalmente es compatible con conda, pero es mejor para resolver conflictos y también es mucho más rápido. Un beneficio adicional es que todos los usuarios de su configuración usarán el mismo solucionador de paquetes, independientemente de la versión de Conda instalada localmente.
  4. De forma predeterminada, use Poetry para agregar dependencias de Python. Instale paquetes a través de Conda si hay una razón para hacerlo (por ejemplo, para obtener una versión habilitada para CUDA). En tal caso, es mejor especificar la versión exacta del paquete en environment.ymly después de instalarlo, para agregar una entrada con la misma especificación de versión a Poetry’s pyproject.toml (sin que ^ o ~ antes del número de versión). Esto le permitirá a Poetry saber que el paquete está allí y no debe actualizarse.
  5. Si utiliza canales diferentes que ofrecen los mismos paquetes, es posible que no resulte obvio de qué canal se descargará un paquete en particular. Una solución es especificar el canal para el paquete usando la notación :: (ver el pytorch entrada a continuación), y otra solución es habilitar prioridad de canal estricta. Desafortunadamente, en Conda 4.x no hay forma de habilitar esta opción a través de environment.yml.
  6. Tenga en cuenta que Python agrega paquetes de sitio de usuario a sys.path, lo que puede causar falta de reproducibilidad si el usuario ha instalado paquetes de Python fuera de los entornos de Conda. Una posible solución es asegurarse de que el PYTHONNOUSERSITE variable de entorno se establece en True (o a cualquier otro valor no vacío).

Ejemplo

environment.yml:

name: my_project_env
channels:
  - pytorch
  - conda-forge
  # We want to have a reproducible setup, so we don't want default channels,
  # which may be different for different users. All required channels should
  # be listed explicitly here.
  - nodefaults
dependencies:
  - python=3.10.*  # or don't specify the version and use the latest stable Python
  - mamba
  - pip  # pip must be mentioned explicitly, or conda-lock will fail
  - poetry=1.*  # or 1.1.*, or no version at all -- as you want
  - tensorflow=2.8.0
  - pytorch::pytorch=1.11.0
  - pytorch::torchaudio=0.11.0
  - pytorch::torchvision=0.12.0

# Non-standard section listing target platforms for conda-lock:
platforms:
  - linux-64

virtual-packages.yml (puede usarse, por ejemplo, cuando queremos conda-lock para generar archivos de bloqueo habilitados para CUDA incluso en plataformas sin CUDA):

subdirs:
  linux-64:
    packages:
      __cuda: 11.5

Configuración por primera vez

Puede evitar jugar con el entorno de arranque y simplificar el siguiente ejemplo si tiene conda-lock, mamba y poetry ya instalado fuera de su entorno de destino.

# Create a bootstrap env
conda create -p /tmp/bootstrap -c conda-forge mamba conda-lock poetry='1.*'
conda activate /tmp/bootstrap

# Create Conda lock file(s) from environment.yml
conda-lock -k explicit --conda mamba
# Set up Poetry
poetry init --python=~3.10  # version spec should match the one from environment.yml
# Fix package versions installed by Conda to prevent upgrades
poetry add --lock tensorflow=2.8.0 torch=1.11.0 torchaudio=0.11.0 torchvision=0.12.0
# Add conda-lock (and other packages, as needed) to pyproject.toml and poetry.lock
poetry add --lock conda-lock

# Remove the bootstrap env
conda deactivate
rm -rf /tmp/bootstrap

# Add Conda spec and lock files
git add environment.yml virtual-packages.yml conda-linux-64.lock
# Add Poetry spec and lock files
git add pyproject.toml poetry.lock
git commit

Uso

La configuración anterior puede parecer compleja, pero se puede usar de una manera bastante simple.

Creando el ambiente

conda create --name my_project_env --file conda-linux-64.lock
conda activate my_project_env
poetry install

Activando el entorno

conda activate my_project_env

Actualizando el entorno

# Re-generate Conda lock file(s) based on environment.yml
conda-lock -k explicit --conda mamba
# Update Conda packages based on re-generated lock file
mamba update --file conda-linux-64.lock
# Update Poetry packages and re-generate poetry.lock
poetry update

  • ¿Cómo especificas el entorno a usar desde tu terminal? ¿Activáis el ambiente de conda y poesía?

    – MadmanLee

    13 de mayo a las 16:52

  • @MadmanLee He proporcionado algunos ejemplos detallados ahora. No dude en preguntar si algo no está claro.

    – michau

    23 de mayo a las 19:56


  • ¿La poesía se instala en el entorno conda o en su propio entorno virtual? Veo que no estás alterando poetry configpor ejemplo, ajuste poetry config virtualenvs.create false --local, ¿así que supongo que la poesía creará su propia venv? Si no, ¿qué es lo que impide que la poesía haga un venv? ¿Y este comportamiento sería el mismo si la poesía se instalara globalmente (en lugar de en el conda env)?

    – James Owers

    28 de junio a las 15:09

  • @JamesOwers Poetry se está instalando en el entorno de Conda. Poetry detecta cuando se activa un entorno Conda, y no crea un venv entonces. Eso probablemente también funcionaría con Poetry instalado globalmente, pero creo que es mejor especificar Poetry en environment.yml e instálelo dentro de Conda env, de modo que todas las dependencias del proyecto se enumeren explícitamente y se pueda rastrear sus versiones.

    – michau

    29 de junio a las 12:48

  • @Aramus Tienes razón, ¡arreglado!

    – michau

    19 de julio a las 15:13

Para cualquiera que use la respuesta de @michau pero tenga problemas para incluir poesía en el environment.yml. Actualmente, las versiones de poesía 1.2 o superior no son apoyado por conda-forja. Todavía puedes incluir poesía v1.2 en el .yml con la siguiente como alternativa:

dependencies:
  - python=3.9.*
  - mamba
  - pip 
  - pip:
    - "poetry>=1.2"

¿Ha sido útil esta solución?