Nie możesz wybrać więcej, niż 25 tematów Tematy muszą się zaczynać od litery lub cyfry, mogą zawierać myślniki ('-') i mogą mieć do 35 znaków.
To repozytorium jest zarchiwizowane. Możesz wyświetlać pliki i je sklonować, ale nie możesz do niego przepychać zmian lub otwierać zgłoszeń/Pull Requestów.

05-virtualenv.rst 6.6 KiB

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