chore: actualiza a la nueva versión de uv

[albertotb]

uv ha añadido soporte para gestionar proyectos. Se prueba en esta PR

Relacionado: https://astral.sh/blog/uv-unified-python-packaging

EDIT:

• Ejemplo de FastAPI oficial: https://github.com/astral-sh/uv-fastapi-example
• Hilos discutiendo mejoras para Docker:
  • Allow users to install a project's dependencies, without the project itself astral-sh/uv#4028
  • Docker: feedback on docs and workflow with frozen/locked dependencies and --require-hashes astral-sh/uv#6451

De esos últimos hilos, probablemente queremos añadir el --frozen y el --no-locals cuando lo implementen.

Closes #43
Closes #48
Closes #49

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 56.52%. Comparing base (8349e19) to head (0208bb6).

Files with missing lines	Patch %	Lines
template/api.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #47   +/-   ##
=======================================
  Coverage   56.52%   56.52%           
=======================================
  Files           4        4           
  Lines          46       46           
=======================================
  Hits           26       26           
  Misses         20       20           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[davidggphy]

es el uv.lock dependiente del SO?

REspondido: SI
Critically, the lockfile is cross-platform, in that it can be used to install a given project on any platform, regardless of where it was generated. uv defines a unique solution for every platform, producing a readable and auditable lockfile that defines exactly which packages will be installed.

[davidggphy]

asumo que este archivo se crea automaticamente. De dónde sale lo de >=3.9, <3.12? es decir, se fija la versión a 3.11 en el .python-version, de dónde saca que es un rango?

[albertotb]

Si. Sale de pyproject.toml. El .python-version es la versión recomendada de desarrollo. Se pueden poner varias en ese fichero también, pero a mi me gusta poner una. Hay dos casos de uso diferenciados:

• librería/paquete: como doraemon. Queremos soportar varias versiones de Python, actualmente 3.9 - 3.12. En .python-version escribes una versión, actualmente la 3.11, que es la que se usa para desarrollar y ejecutar algunas herramientas. No importa mucho porque hay que escribir código Python compatible con todas y testear con todas.
• aplicación. Aquí solo soportamos una versión de Python, que se escribe en el .python-version. En estos casos en pyproject.toml también hay que poner algo como >=3.11, <3.12, que solo es una versión. uv haría lo propio en uv.lock.

El resumen es que la versión de Python de .python-version es importante para aplicaciones, y pyproject.toml para librerías. Pero como ambos repos tienen ambos ficheros, hay que hacer los ajustes de arriba.

[davidggphy]

Muchas gracias, clarisimo. Entonces para un proyecto en particular hay que retocar el pyproject.toml. Viendo que el uso más común es proyecto más que librería, conviene cambiar el valor en pyproject.toml a >=3.11, <3.12?

[albertotb]

Podríamos cambiarlo, pero si por ejemplo empezamos a usar Python 3.12 en los proyectos habría que editarlo después igualmente, con lo que tampoco veo mucha ganancia.

[davidggphy]

Una de las cosas que es útil cuando se está desarrollando, es que la propia librería se ejecuta en modo editable utilizando el pip install -e .

No consigo ver si eso está implementado en los cambios actuales.

Pero viene explicado el cómo hacerlo con fuentes externas aquí, pero en este caso me refiere a la propia librería. No sé si al ejecutar todo con uv run al vuelo coge lo existente.

[albertotb]

Esto está todavía en fase experimental. Sobre el -e, si ejecutas las cosas con uv run no es problema porque regenera el fichero uv.lock e instala todo automáticamente, con lo que siempre tienes la última versión. No tengo claro que pasa si ejecutas sin uv run, activando el entorno manualmente.

[albertotb]

@davidggphy Parece que uv sync instala la la librería de root, a la que hace referencia pyproject.toml en formato editable por defecto. Se puede comprobar con el siguiente experimento:

• Instalar librería y dependencias con uv sync
• Activar el venv
• Comprobar que la librería es importable
• Editar un fichero
• Comprobar que la librería se ha actualizado

En la siguiente sesión entre el primer y segundo import se editó el fichero main.py añadiendo la string TEST y no se ejecutá ningún comando de uv (ni sync, ni run ni lock):

[davidggphy]

@davidggphy Parece que uv sync instala la la librería de root, a la que hace referencia pyproject.toml en formato editable por defecto.

Perfecto, estaba pensando en el modo de desarrollo con notebooks y autoreload en el que vas editando algún módulo a la vez. Que para que funcione cuando tienes el proyecto como librería, debe estar en modo editable

[albertotb]

@davidggphy Parece que uv sync instala la la librería de root, a la que hace referencia pyproject.toml en formato editable por defecto.

Perfecto, estaba pensando en el modo de desarrollo con notebooks y autoreload en el que vas editando algún módulo a la vez. Que para que funcione cuando tienes el proyecto como librería, debe estar en modo editable

Para notebooks solo hace falta añadir ipykernel, normalmente a las dependencias de desarrollo y VSCode detecta el kernel del venv automáticamente. Lo único que no funciona es intalar ipykernel con el prompt de VSCode, hay que hacerlo con la terminal.

[albertotb]

Para solucionar #48 se usa la flag "system" en el hook de mypy en pre-commit. Eso quiere decir que hay que intalarlo explicitamente en la Action. Sin embargo, tiene pinta que ahora mismo en la Action uv está instalando las dependencias en un entorno virtual en lugar de en el Python del sistema, por lo que pre-commit no encuentra mypy.

Posible parche mientras aqui: astral-sh/uv#5964