Adds support dad/dev and Pipfile/pipenv

[mlhamel]

Description

This PR is adding support for dev/dad and Pipfile/pipenv

Please note

translate seems to have a lot of dependencies but we'll see in a future PR if we can drop it

[ygingras]

Presque! Je pense que le Pipfile.lock devrait aller dans .gitignore sinon ca entre en conflit avec les états des venvs des autre devs et cache le fait qu'ils doivent faire une mise à jour quand les deps changent.

Autrement, je suis très en faveur parce que je pense que pipenv est très cool, surtout lorsque combiné à direnv.

[merwok]

Les lockfiles de dépendances devraient être committés 😮 Est-ce que pipenv fait de quoi pas correct qui le rend différent de pip-tools npm yarn cargo poetry?

[ygingras]

J'imagine que j'ai mal compris la doc. Le lockfile est recommandé pour les déploiements, je n'ai pas de troubles avec cette idée. Mais si deux devs modifient leur venv de dev, le lockfile va être en conflit. Le pipfile va aussi être en conflit, mais ca c'est une résolution facile dans un éditeur de texte alors que le lockfile doit être considéré comme opaque. C'est quoi la bonne stratégie? Le nuker, merger le pipfile, puis le regénérer avec pipenv lock?

[merwok]

Je ne suis pas sûr de comprendre ce que veut dire concrètement:

si deux devs modifient leur venv

Si je change un dépendance du projet, je mets à jour pipfile et lock, et je mets à jour le code si nécessaire.
Les autres devs ont besoin de récupérer cette modif :)

Ma question sur pipenv n’était pas rhétorique: je n’ai pas roulé pipenv depuis longtemps, j’utilise majoritairement pip-tools, pour des clients pipenv parfois, et aussi npm côté frontend. Leurs fichiers lock ne contiennent pas d’infos locales qui changent sans raison entre deux devs. (Un exemple, la version de Python à utiliser doit faire partie des fichiers committés (la version X.Y je pense, pas X.Y.Z), mais le chemin local exact du virtualenv n’a pas sa place là.) Est-ce que pipenv a des lockfiles instables?

[mlhamel]

Par contre je ne suis plus convaincue par Pipenv en fait j'utilise avec plaisirs poetry depuis cet automne et le fait que ce dernier se base sur le pyproject.toml (PEP 518) est quand même vraiment plus aligné sur la direction que semble prendre le packaging de Python.

Je propose qu'on ferme cette PR et qu'on y introduise le support poetry.

Pour ce qui est du lock file je suis daccord avec @merwok on devrait vraiment le commité car ainsi, chaque update de package passe par une PR, le CI et ca permet d'avoir un environment cohérent d'un dev a l'autre.

[ygingras]

C'est bon pour moi. Je n'ai jamais essayé poetry, mais un petit projet comme celui ci semble être un bon endroit pour m'y initier.

[merwok]

Poetry a quelques détails qui ne sont pas standard mais globalement c’est correct.

Depuis que la PR a été ouverte, dad/dev est devenu devbuddy, donc on devrait adapter la config et la doc pour ça aussi.