Surnager dessus les virtualisations, devcontainers

Bonjour,

Je cherche désespérément la bonne configuration pour coder proprement.
Eviter l'enfer et engrenage des dépendances sur un gros projet.

PyEnv me permettrait d'avoir N versions de python sur mon poste (ou mon container) afin de rendre hermétique leur usage. Super.

Docker me permet de créer un container avec un "système" hermétique, et avec les volumes je peux même sauver en local mes sources, donc GITer celles-ci et coder sans influer ma machine. Super.

Niveau IDE on me pousse vers VSCode et avec l'extension dev-container c'est top, on peut coder dans un container et donc cumuler l'attrait de l'IDE et rendre le code Hermétique.
En plus il accèpte ma méthode de travail en cellules via les fichiers .ipynb

Sinon, je peux rester sur un bon vieux Jupyter notebook qui me permet jusqu'à aujourd'hui de coder correctement et tester via cellule avant l'export .py

Et là ça se complique...

Humm en gestion de dépendances, Poetry a l'air top. Mais après quelques jours d'enfer je ne trouve pas moyen de le faire tourner sur un dev-container.
J'ai testé dans tous les sens, Container d'OS sur lequel j'installe tout (Python, Poetry, Jupyter notebook), ou Container déjà Python ou déjà Jupyter... dans tous les cas Poetry ne sert à rien et je parviens pas à qu'il se combine avec mon container/jupyter

J'avoue être paumé.
Je me dis que des profils qui ont vécus de genre de galère/question il doit en avoir ici, d'ou mon message pour chercher à discuter avec vous de cela.


Mon objectif est bien de coder physiquement sur mon poste local (macOS), tout en ayant un système hermétique (python, librairies)
Jouer avec un outil de gestion de dépendances pour éviter les clashs dans 12 mois et coder en Jupyter (ça me va)

A vous lire !!
Cordialement,

Salut,

A l'instant T, on commence le développement d'une application qui dépendra des versions x.y des bibliothèques a, b, c,... A T+1, on finit le développement et on se propose de faire profiter de l'application a des utilisateurs. Le préalable étant de disposer d'un environnement "semblable".

Les "outils" de gestion des dépendances mentionnés évitent à l'utilisateur de lire le document d'installation pour savoir quoi installer, quelles versions en automatisant la construction de cet environnement.... ce qui sera plus fiable côté résultat.... mais on n'est pas dans une logique de gestion des dépendances mais plutôt de "packaging" pour éviter d'avoir à les gérer: chaque application étant livrée dans sa boite.

Citation:

---

Mon objectif est bien de coder physiquement sur mon poste local (macOS), tout en ayant un système hermétique (python, librairies)

---

Qu'est ce que des outils de packaging (un truc pour déployer l'application) peuvent apporter à l'écriture du code (je n'ai pas encode d'application à déployer)?
note: pour moi, c'est une contrainte. Si je dois livrer sous telle forme, je m'assure de temps en temps que je peux packager mon développement sous cette forme là (avant de faire des tests fonctionnels par exemple).

- W