You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This repo is archived. You can view files and clone it, but cannot push or open issues/pull-requests.

05-virtualenv.rst 5.7 KiB

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