Bonjour,
j’utilise Linux Mint et les mises à jour de Python sont automatiques.
Faut-il faire une mise à jour de la version de Python sous venv et comment ?
Pour les modules , quelle est la procédure de mise à jour ?
Merci d’avance
Bonjour,
j’utilise Linux Mint et les mises à jour de Python sont automatiques.
Faut-il faire une mise à jour de la version de Python sous venv et comment ?
Pour les modules , quelle est la procédure de mise à jour ?
Merci d’avance
D’une version mineur à l’autre (de 3.13.x à 3.13.y) pas besoin de toucher aux venvs.
D’une version à l’autre (3.13 à 3.13) tu devras toucher à tes venvs, et ça ne sera pas discret : tu sauras qu’il faut que tu y touches (pip command not found, etc…).
Pour les mettre à jour tu peux tenter un python -m venv --upgrade .venv (mais si ça ne suffit pas tu peux toujours le supprimer et le recréer).
Pour les versions des paquets installés dans le venv moi j’aime bien avoir :
pyproject.toml avec mes dépendances “larges” (pas épinglées précisément, mais avec des > ou des >= si je sais qu’une dépendance trop vieille ne convient pas a mon projet), comme ça :[project]
dependencies = [
"matplotlib >= 3.1",
"sympy >= 1.2",
]
requirements.txt auto-généré via pip-compile, comme ça :$ pip install pip-tools
$ pip-compile pyproject.toml
pip-compile prend en compte la version de Python avec lequel il est lancé (donc la version du Python du venv dans lequel il est), et te génère un requirements.txt avec les dépendances bien épinglées, pour ta version de Python. Tu peux installer ce que le requirements.txt liste avec pip install -r requirements.txt.
Lorsque ta version de Python change, tu peux re-générer ton requirements.txt pour prendre ça en compte avec un pip-compile --upgrade pyproject.toml.
Tu peux aussi lancer le pip-compile --upgrade pyproject.toml de temps en temps pour avoir des dépendances à jour (n’oublie juste pas de pip install -r requirements.txt et de lancer tes tests avant de commit ce nouveau requirements.txt).
Il existe des outils dits « modernes » qui essayent de tout faire en même temps (ton venv, générer la liste des dépendances épinglées, et les installer, et te commander un café). Je déteste ça : je préfère des outils qui ne font qu’une chose mais qui le font bien. pip ça ne fait qu’installer mais ça le fait bien. pip-compile ça ne fait que générer le requirements.txt mais ça le fait bien. python -m venv ça ne fait que créer des venvs mais ça le fait bien.
merci @mdk , n’étant pas un pro du Python, je ne sais pas où tu places [projet] ?
En regardant un peu ce qu’était un pyproject.toml je me demande si cela correspond à mon utilisation perso. Je n’ai aucun projet de défini et tous mes scripts ne sont jamais diffusés.
Personnellement je n’ai jamais réussi à avoir quelque chose de fonctionnel avec --upgrade sur venv, donc je recrée systématiquement l’environnement virtuel quand je change de version de Python.
bonjour @entwanne , sauf erreur de ma part et comme je ne diffuse aucun script, je ne me suis jamais soucié des versions de Python qui ne m’ont jamais posé de problème (même si une fois j’ai eu incompatibilité entre numpy et pandas, mais c’était de la faute du système d’exploitation).
Donc je reteste régulièrement mes scripts (de toutes façons je relève toujours 1 petite erreur ou 2 à corriger…) et quand certaines instructions sont annoncées “obsolètes” je cherche comment utiliser les nouvelles.
Ma question est plutôt du genre: comment sait-on qu’une nouvelle version de module existe et comment la mettre à jour sachant que pour Python la mise à jour semble (?) automatique via l’OS
Ah je n’avais pas du tout compris le message dans ce sens là.
Dans ce cas, il suffit de régler des dépendances pas trop strictes dans le pyproject.toml et de mettre à jour les paquets, ça fera monter en version ce qui peut l’être.
Sur des gros projets il y a des outils comme renovate qui peuvent aider à ça.
Pour essayer d’être plus clair, je suis sous Linux Mint, n’utilise pas Github (hormis pour déposer des demandes de corrections de bugs) et ai tous mes scripts en local car ils ne servent qu’à moi et sont dans un environnement venv.
Les mise à jour de Python semblent bien se faire en automatique via l’OS, pour les mises à jour des modules je me pose la question.
J’ai essayé un pip list -o qui m’indique que de nombreux modules ne sont pas à jour.
Donc comment faire une mise à jour (en espérant que mon OS accepte ces nouvelles versions, ce qui est pour moi est inconnu car je ne sais pas si il y a une relation entre l’OS et Python), si je dois en faire sous venv.
Désolé pour toutes ces questions de néophyte…
Il me semble qu’mdk a répondu à la question dans son premier message avec pip-compile --upgrade pyproject.toml.
Si tu utilises seulement pip (et non pip-compile comme dans son exemple) et que tes dépendances sont configurées assez large, tu peux faire un pip install --upgrade --upgrade-strategy eager . par exemple pour mettre à jour les dépendances du projet courant.
Par contre pour ce qui est de mettre à jour les versions (majeures par exemple) des dépendances dans ton pyproject.toml ça demande potentiellement de mettre à jour le code de ton projet (pour s’adapter à la nouvelle version justement) donc c’est une opération à faire avec prudence, et là c’est soit manuel soit via des outils dédiés comme je citais.
merci @entwanne .
d’après ce que j’ai pu déchiffrer, pip install --upgrade --upgrade-strategy eagermet à jour tous les modules, or comme ces nouvelles versions ne sont pas forcément dans les dépots de Mint, j’ai peur de casser quelquechose. En lisant un peu de doc, je viens créer un fichier requirements.in et fais pip-compile requirements.in puis un pip-compile --upgrade .
Je vais voir si tout fonctionne après cette mise à jour.
Après ces commandes , je constate qu’aucune mise à jour de module n’a été faite. Cela vous semble normal ?
pip fonctionne de façon indépendante de Mint.
Mint gère les applications et dépendances au niveau du système, pour s’assurer que toutes soient compatibles entre elles.
Depuis quelques années, la PEP 668 assure que seul le système d’exploitation a la main sur les répertoires partagés et donc sur les dépendances qui affecteraient la globalité du système ou de l’utilisateur (et qui pourraient avoir pour effet de casser des programmes installés via le gestionnaire de paquets de l’OS).
Il n’y a donc aucun risque de se marcher dessus, en dehors d’un environnement virtuel, pip devrait refuser l’installation.
Et dans un virtualenv, l’intérêt est justement que ça n’a pas d’impact à l’extérieur de celui-ci.
ok @entwanne . Si je comprends bien je n’ai aucune raison de rechercher les nouvelles versions de modules puisque c’est mon OS qui s’en charge.
Non dans l’environnement virtuel ce n’est pas l’OS qui s’en charge justement, c’est indépendant.
Il faut donc que le projet maintienne (via son pyproject.toml) les spécifications de versions des dépendances compatibles, et utiliser pip ou pip-compile pour mettre à jour les dépendances dans le venv en fonction de ces specs.
OK, j’avais tout faux.
comme j’ai fait pip-compile –upgrade puis pip-compile requirements.inet que je n’ai eu aucune différence dans les requirements.txt c’est que tout est à jour n’est-ce pas ?
C’est que les versions dans le fichier généré sont les plus à jour possibles pour celles spécifiées dans le pyproject.toml, mais si les spécifications sont trop strictes, ce ne sont pas forcément les versions les plus à jour.
je n’ai pas de pyproject.tomlcar je ne sais pas vraiment comment le créer, c’est pour cela que je me suis tourné vers un requirements.in qui est plus simple à créer pour moi.
La même règle s’applique alors, si les dépendances sont trop strictes, rien n’est mis à jour.
(pour ce qui est du pyproject.toml, c’est tout simple)
j’ai fait un pip-sync requirements.txt qui m’a fait toutes les mises à jour: j’ai bien fait ?
Pour ce qui concerne le pyproject.toml je ne suis pas sur que cela soit simple mais je vais regarder cela de plus près ![]()
pip-sync permet de faire correspondre les versions des paquets de l’environnement courant avec les versions écrites dans le fichier requirements.txt donné.
oui, j’ai bien une mise à jour avec des versions différentes entre l’environnement standard et l’environnement venv quand j’utilise pip freeze dans les 2 cas.
J’ai essayé pip-compile -o requirements.txt pyproject.toml mais j’ai un souci avec le chemin du pyproject.toml .
Bonjour, je reviens un peu à la charge suite à différentes manip :
ayant abandonné le fichier pyproject.toml au profit de requirements.in pour une question de simplicité (scripts locaux, pour rappel), j’ai créé ce dernier avec ce dont je me rappelais comme ayant été installé avec pip install, mais comme je voudrais être exhaustif, je me suis tourné vers l’installation de pipdeptree qui semble me donner la liste des modules installés avec pip install.
Mais il y a un hic car numpy est associé à pandas mais demande à être installé séparément et requests est associé à requests-html mais demande aussi son installation séparée.
pandas==3.0.2
├── numpy [required: >=1.26.0, installed: 2.4.4]
└── python-dateutil [required: >=2.8.2, installed: 2.9.0.post0]
└── six [required: >=1.5, installed: 1.17.0]
requests-html==0.10.0
├── requests [required: Any, installed: 2.33.1]
│ ├── charset-normalizer [required: >=2,<4, installed: 3.4.7]
│ ├── idna [required: >=2.5,<4, installed: 3.13]
│ ├── urllib3 [required: >=1.26,<3, installed: 1.26.20]
│ └── certifi [required: >=2023.5.7, installed: 2026.4.22]
ma question est donc : y-a-t-il un moyen de savoir rigoureusement ce qui a été installé avec pip install ? désolé d’insister…