Switch to poetry for dependencies management

[fabienheureux]

Description succincte du problème résolu

https://www.notion.so/accelerateur-transition-ecologique-ademe/La-gestion-des-d-pendances-ne-semble-pas-optimale-1596523d57d7807a91b7d9eaa85ff139?pvs=4

Ça tourne sur https://dashboard.scalingo.com/apps/osc-fr1/quefairedemesobjets-preprod/deploy/baf37131-258f-4af8-a506-b1c023c58ac7

Utilisation de Poetry ✍️

Désormais toutes les installations de dépendance, gestion d'environnement virtuel, déploiements passent par poetry.

Intérêt (voir https://www.notion.so/accelerateur-transition-ecologique-ademe/Synchronisation-des-Techos-1756523d57d78090be2df64e55e29142?pvs=4#17c6523d57d780b8a399cab5b559beb0)

• Un lockfile qui fixe les dépendances
• Une résolution des dépendances à l'installation qui vérifie les contraintes de version et empêche l'installation de dépendances incompatibles

Dependabot 🤖

à tester sur le moyen / long terme, mais je crois que dependabot va uniquement mettre à jour le poetry.lock.
On est donc pas exemptés de mettre à jour les versions majeures manuellement dans le pyproject si on souhaite fixer une version spécifique.

CI 🏗️

Tout est fonctionnel et testé

Déploiements 🚀

Scalingo supporte les poetry.lock, j'ai testé un déploiement en staging et on est bon ! 🎉

Docker 🐳

J'en ai profité pour assainir les dockerfile :

• Utilisation de multi stage builds https://docs.docker.com/build/building/multi-stage/
• On a donc plusieurs étapes
  • build des dépendances système (gdal)
  • build / installation des dépendances python
  • runtime
• modernisation de l'installation de awscli
• build de psycopg2 plutôt qu'utilisation de psycopg2 binary

On copie le contenu de chaque étape de build dans le runtime.
Les avantages

• On embarque pas de compilateur C etc en prod : images plus légères, risques de sécurité réduits...entre autres

En local

Idéalement il faudrait que vous réinitialisiez votre environnement local pour qu'on soit sûr de l'absence d'effets de bords

• Installation de Poetry
• Suppression de l'environnement virtuel
• Re-création via poetry

TODO

• Mettre à jour le readme
• Mettre à jour les Dockerfile

Type de changement :

• Bug fix
• Nouvelle fonctionnalité
• Mise à jour de données / DAG
• Les changements nécessitent une mise à jour de documentation
• Refactoring de code (explication à retrouver dans la description)

Auto-review

Les trucs à faire avant de demander une review :

• J'ai bien relu mon code
• La CI passe bien
• En cas d'ajout de variable d'environnement, j'ai bien mis à jour le .env.template
• J'ai ajouté des tests qui couvrent le nouveau code

[maxcorbeau]

OK donc si je comprends bien:

• CI: on préfixe les commandes de build avec poetry (pour que poetry charge son environnement et éxecute ce qui suit)
• poetry.toml: conf de base poetry
• pyproject.toml: c'est maintenant là qu'on vient définir les différents requirements
• *requirements.in/txt: tout ça dégage 🥳
• Dockerfile: petites modifs pour intégrer poetry

J'ai manqué un truc important?

Peux-tu stp faire un résumé des commandes à utiliser au quotidien? (le workflow standard)