A file format to record Python dependencies for installation reproducibility
C’était pas le but du fichier requirements.txt ?
Je ne suis pas un fin connaisseur de Python mais je l’ai utilisé et je trouve que c’est un langage avec d’énormes qualités et surtout une philosophie judicieuse. Par contre, j’ai toujours vu d’un œil méfiant les programmes nécessitant des dépendances du genre 3.2.4=<bidule=<3.3.1, voire machin==2.3.9a+git_ab22ef45 (j’exagère mais ya quand même un peu de ça j’ai l’impression).
Ceci dit je pense que c’est aussi lié à la propension des beaucoup de gens de recourir à 36 bibliothèques dont seulement cinq à dix pourcents de chacune est utilisée. Sa partie la moins stabilisée, ça va de soi, c’est plus drôle !
Alors que bien souvent une petite quantité de jus de cerveau et un nombre relativement faible de lignes de code utilisant les builtins Python n’était pas insurmontable pour au moins la moitié des bibliothèques, et nettement plus aisé à maintenir.
C’est évidemment pas propre à Python ça, mais j’ai l’impression que c’est particulièrement courant en Python. Plus qu’en Perl par exemple.
Le requirements.txt n'est pas vraiment un "lockfile" car, sauf s'il est généré à partir de pip freeze, il ne "pin" pas les dépendances à une version exact, et ne force pas la présence des dépendances indirectes.
De plus, il n'était pas standard, dans le sens ou Python n'avait, jusqu'à maintenant, codifié le format du fichier.
Grâce à cette PEP, tout les outils (uv, poetry, pdm, pipenv, …) qui décideront de l'implémenter seront compatibles les uns avec les autres (réduisant ainsi la friction bien connue du packaging Python).
Par contre il semble qu’il manque une pièce ou deux dans le standard actuel pour accepter l’ensemble des options actuellement disponibles dans uv. C’est assez surprenant étant donné que les implémentations actuelles (uv, poetry, pdm) ont été consultées pour arriver à ce standard.
Je pensais que c’était le cas. Cela dit si je ne raconte pas de bêtise, ça implique que toutes les dépendances soient installées via pip, qu’il n’y en ait pas qui soient installées par un autre moyen (packages systèmes ou à la main (voire au pied!)), mais que tout projet/code Python dépassant le stade de script de POC de coin de table utilisait systématiquement un venv et du pip dedans.
Mais c’est sûr que pour la même raison que Python impose l’indentation du code il se doit d’être tout aussi coercitif pour que tout code Python présente bien, ni trop négligé ni trop pimpant, qu’il soit bien normal comme il faut, « pythonesque » comme on dit. Si c’est la fête du slip dans le requirements.txt alors en effet ça le fait pas du tout !
# Le commentaire
Posté par David Delassus (site web personnel) . Évalué à 2 (+0/-0).
https://discuss.python.org/t/pep-751-one-last-time/77293/150
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Lockfile
Posté par lolop (site web personnel) . Évalué à 4 (+2/-0).
…je pensais que c'était un module standard (avec les implémentations pour les différentes plateformes) pour gérer les verrous fichiers…
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Il serait temps ?
Posté par Marotte ⛧ . Évalué à 4 (+1/-0).
C’était pas le but du fichier
requirements.txt?Je ne suis pas un fin connaisseur de Python mais je l’ai utilisé et je trouve que c’est un langage avec d’énormes qualités et surtout une philosophie judicieuse. Par contre, j’ai toujours vu d’un œil méfiant les programmes nécessitant des dépendances du genre 3.2.4=<bidule=<3.3.1, voire machin==2.3.9a+git_ab22ef45 (j’exagère mais ya quand même un peu de ça j’ai l’impression).
Ceci dit je pense que c’est aussi lié à la propension des beaucoup de gens de recourir à 36 bibliothèques dont seulement cinq à dix pourcents de chacune est utilisée. Sa partie la moins stabilisée, ça va de soi, c’est plus drôle !
Alors que bien souvent une petite quantité de jus de cerveau et un nombre relativement faible de lignes de code utilisant les builtins Python n’était pas insurmontable pour au moins la moitié des bibliothèques, et nettement plus aisé à maintenir.
C’est évidemment pas propre à Python ça, mais j’ai l’impression que c’est particulièrement courant en Python. Plus qu’en Perl par exemple.
[^] # Re: Il serait temps ?
Posté par David Delassus (site web personnel) . Évalué à 5 (+3/-0).
Le
requirements.txtn'est pas vraiment un "lockfile" car, sauf s'il est généré à partir depip freeze, il ne "pin" pas les dépendances à une version exact, et ne force pas la présence des dépendances indirectes.De plus, il n'était pas standard, dans le sens ou Python n'avait, jusqu'à maintenant, codifié le format du fichier.
Grâce à cette PEP, tout les outils (
uv,poetry,pdm,pipenv, …) qui décideront de l'implémenter seront compatibles les uns avec les autres (réduisant ainsi la friction bien connue du packaging Python).https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Il serait temps ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Et il est lié à une version précise de Python, et un environnement précis (windows, linux, arm, …)
C’est, parmi les formats de lock existants (non-standard), le pire.
[^] # Re: Il serait temps ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Oui je l’espère !
Par contre pas
pipenv, qui n’utilise paspyproject.toml.Il n’est d’ailleurs pas cité dans la PEP.
[^] # Re: Il serait temps ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
uv a un ticket sur cette PEP, indiquant qu’ils vont d’abord commencer par le gérer en tant que format d’export
https://github.com/astral-sh/uv/issues/12584
Par contre il semble qu’il manque une pièce ou deux dans le standard actuel pour accepter l’ensemble des options actuellement disponibles dans uv. C’est assez surprenant étant donné que les implémentations actuelles (uv, poetry, pdm) ont été consultées pour arriver à ce standard.
Je n’ai rien trouvé chez Poetry.
[^] # Re: Il serait temps ?
Posté par Marotte ⛧ . Évalué à 3 (+0/-0).
Je pensais que c’était le cas. Cela dit si je ne raconte pas de bêtise, ça implique que toutes les dépendances soient installées via pip, qu’il n’y en ait pas qui soient installées par un autre moyen (packages systèmes ou à la main (voire au pied!)), mais que tout projet/code Python dépassant le stade de script de POC de coin de table utilisait systématiquement un venv et du pip dedans.
Mais c’est sûr que pour la même raison que Python impose l’indentation du code il se doit d’être tout aussi coercitif pour que tout code Python présente bien, ni trop négligé ni trop pimpant, qu’il soit bien normal comme il faut, « pythonesque » comme on dit. Si c’est la fête du slip dans le requirements.txt alors en effet ça le fait pas du tout !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.