Du kannst nicht mehr als 25 Themen auswählen Themen müssen entweder mit einem Buchstaben oder einer Ziffer beginnen. Sie können Bindestriche („-“) enthalten und bis zu 35 Zeichen lang sein.
Dieses Repo ist archiviert. Du kannst Dateien sehen und es klonen, kannst aber nicht pushen oder Issues/Pull-Requests öffnen.

05-virtualenv.md 5.4 KiB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137
  1. +++
  2. title = "Environnements virtuels"
  3. weight = 5
  4. +++
  5. # Environnements virtuels
  6. La solution à la question de la fin du chapitre précédent est d'utiliser un *environnement virtuel*
  7. (*virtualenv* en abrégé).
  8. C'est un répertoire *isolé* du reste du système.
  9. Il se crée par exemple avec la commande `python3 -m venv foo-venv`. où `foo-venv` est un répertoire quelconque.
  10. ## Aparté : python3 -m venv sur Debian
  11. La commande `python3 -m venv` fonctionne en général partout, dès l'installation de Python3 (*out of the box*, en Anglais), *sauf* sur Debian et ses dérivées [^5].
  12. Si vous utilisez Debian, la commande pourrait ne pas fonctionner. En fonction des messages d'erreur que vous obtenez, il est possible de résoudre le problème en :
  13. * installant le paquet `python3-venv`,
  14. * ou en utilisant d'abord `pip` pour installer `virtualenv`, avec `python3 -m pip install virtualenv --user` puis en lançant `python3 -m virtualenv foo-venv`.
  15. ## Comportement de python dans le virtualenv
  16. Ce répertoire contient de nombreux fichiers et dossiers, et notamment un binaire dans `foo-venv/bin/python3`.
  17. Voyons comment il se comporte en le comparant au binaire `/usr/bin/python3` habituel :
  18. ```
  19. $ /usr/bin/python3 -c 'import sys; print(sys.path)'
  20. ['',
  21. ...
  22. '/usr/lib/python3.7',
  23. '/usr/lib/python3.7.zip',
  24. '/usr/lib/python3.7/lib-dynload',
  25. '/home/dmerej/.local/lib/python3.7/site-packages',
  26. '/usr/lib/python3.7/site-packages'
  27. ]
  28. $ /home/dmerej/foo-venv/bin/python -c 'import sys; print(sys.path)'
  29. ['',
  30. '/usr/lib/python3.7',
  31. '/usr/lib/python3.7.zip',
  32. '/usr/lib/python3.7/lib-dynload',
  33. '/home/dmerej/foo-venv/lib/python3.7/site-packages,
  34. ]
  35. ```
  36. À noter:
  37. * Le répertoire "global" dans `~/.local/lib` a disparu
  38. * Seuls quelques répertoires systèmes sont présents (ils correspondent plus ou moins à l'emplacement des modules de la bibliothèque standard)
  39. * Un répertoire *au sein* du virtualenv a été rajouté
  40. Ainsi, l'isolation du virtualenv est reflété dans la différence de la valeur de `sys.path`.
  41. Il faut aussi préciser que le virtualenv n'est pas complètement isolé du reste du système. En particulier, il dépend encore du binaire Python utilisé pour le créer.
  42. Par exemple, si vous utilisez `/usr/local/bin/python3.7 -m venv foo-37`, le virtualenv dans `foo-37` utilisera Python 3.7 et fonctionnera tant que le binaire `/usr/local/bin/python3.7` existe.
  43. Cela signifie également qu'il est possible qu'en mettant à jour le paquet `python3` sur votre distribution, vous rendiez inutilisables les virtualenvs créés avec l'ancienne version du paquet.
  44. ## Comportement de pip dans le virtualenv
  45. D'après ce qui précède, le virtualenv ne devrait contenir aucun module en dehors de la bibliothèque standard et de `pip` lui-même.
  46. On peut s'en assurer en lançant `python3 -m pip freeze` depuis le virtualenv et en vérifiant que rien ne s'affiche.
  47. ```
  48. $ python3 -m pip freeze
  49. # de nombreuses bibliothèques en dehors du virtualenv
  50. apipkg==1.5
  51. cli-ui==0.9.1
  52. gaupol==1.5
  53. tabulate==0.8.4
  54. $ /home/dmerej/foo-venv/bin/python3 -m pip freeze
  55. # rien :)
  56. ```
  57. On peut alors utiliser le module `pip` *du virtualenv* pour installer des bibliothèques dans celui-ci :
  58. ```
  59. $ /home/dmerej/foo-venv/bin/python3 -m pip install cli-ui
  60. Collecting cli-ui
  61. Using cached https://pythonhosted.org/..cli_ui-0.9.1-py3-none-any.whl
  62. Collecting colorama (from cli-ui)
  63. Using cached https://pythonhosted.org/..colorama-0.4.1-py2.py3-none-any.whl
  64. Collecting unidecode (from cli-ui)
  65. Using cached https://pythonhosted.org/..Unidecode-1.0.23-py2.py3-none-any.whl
  66. Collecting tabulate (from cli-ui)
  67. Installing collected packages: colorama, unidecode, tabulate, cli-ui
  68. Successfully installed cli-ui-0.9.1 colorama-0.4.1 tabulate-0.8.3
  69. unidecode-1.0.23
  70. ```
  71. Cette fois, aucune bibliothèque n'est marquée comme déjà installée, et on récupère donc `cli-ui` et toutes ses dépendances.
  72. On a enfin notre solution pour résoudre notre conflit de dépendances :
  73. on peut simplement créer un virtualenv par projet. Ceci nous permettra
  74. d'avoir effectivement deux versions différentes de `cli-ui`, isolées les
  75. unes des autres.
  76. ## Activer un virtualenv
  77. Devoir préciser le chemin du virtualenv en entier pour chaque commande peut devenir fastidieux ; heureusement, il est possible *d'activer* un virtualenv, en lançant une des commandes suivantes :
  78. * `source foo-venv/bin/activate` - si vous utilisez un shell POSIX
  79. * `source foo-venv/bin/activate.fish` - si vous utilisez Fish
  80. * `foo-venv\bin\activate.bat` - sous Windows
  81. Une fois le virtualenv activé, taper `python`, `python3` ou `pip` utilisera les binaires correspondants dans le virtualenv automatiquement,
  82. et ce, tant que la session du shell sera ouverte.
  83. Le script d'activation ne fait en réalité pas grand-chose à part modifier la variable `PATH` et rajouter le nom du virtualenv au début de l'invite de commandes :
  84. ```
  85. # Avant
  86. user@host:~/src $ source foo-env/bin/activate
  87. # Après
  88. (foo-env) user@host:~/src $
  89. ```
  90. Pour sortir du virtualenv, entrez la commande `deactivate`.
  91. ## Conclusion
  92. Le système de gestions des dépendances de Python peut paraître compliqué et bizarre, surtout venant d'autres langages.
  93. Mon conseil est de toujours suivre ces deux règles :
  94. * Un virtualenv par projet et par version de Python
  95. * Toujours utiliser `pip` *depuis* un virtualenv
  96. Certes, cela peut paraître fastidieux, mais c'est une méthode qui vous évitera probablement de vous arracher les cheveux (croyez-en mon expérience).