Je pense que le nombre de Rubyistes qui commencent à toucher Python a augmenté en raison du boom de l'apprentissage automatique. À ce moment-là, la construction de l'environnement sera probablement un problème. En Ruby, rbenv est la norme de facto, mais pour une raison quelconque, il existe de nombreuses opinions négatives sur pyenv en Python.
J'utilise pyenv et je le trouve utile. J'utilise aussi rarement Ruby, mais j'ai également étudié les différences entre les piles d'outils de Ruby et Python. (Référence: Comparaison de gem, bundler et pip, venv)
De ce point de vue, je voudrais résumer les différences entre les environnements Ruby et Python que les utilisateurs de Ruby devraient connaître lorsqu'ils décident comment utiliser pyenv pour eux-mêmes.
tl;dr
Même si je l'explique soigneusement, il y a des gens qui ont immédiatement lu négativement que "je dois lire un article aussi long pour utiliser Python", donc je vais le résumer en 4 lignes.
pyenv local n'est pas nécessaire.La répartition des rôles des outils de gestion de packages est légèrement différente entre Ruby et Python. Le pip de Python a des fonctionnalités telles que la résolution des dépendances et le verrouillage de version, donc à cet égard, il inclut une partie du rôle de Bundler ainsi que de gem.
D'autre part, la fonction pour gérer les paquets indépendamment pour chaque projet (`` bundle install --path '' de Bundler) est venv. J'utilise un outil appelé. [^ 1](Référence: [bundler --path and venv](http://qiita.com/methane/items/570728ad3e79c74f4e9e#bundler-%E3%81%AE --- path-% E3% 81% A8 -venv)))
La grande différence entre venv et `` bundle install --path '' est que venv se comporte comme un Python configuré indépendamment, plutôt que de simplement stocker des paquets. C'est ce qu'on appelle un «environnement virtuel». L'environnement virtuel est plus compact que l'environnement Python réellement installé car la bibliothèque standard est la même que le Python d'origine. Voir l'exemple suivant.
$ python3 -m venv .venv # .Créez un environnement virtuel dans un répertoire nommé venv.
$ ls -F .venv/
bin/ include/ lib/ pip-selfcheck.json pyvenv.cfg
$ .venv/bin/pip install tornado
Collecting tornado
Installing collected packages: tornado
Successfully installed tornado-4.5.1
$ .venv/bin/python
Python 3.6.1 (default, May 18 2017, 16:23:51)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import tornado
Comme vous pouvez le voir, dans un environnement virtuel, vous pouvez appeler pip install '' sans options comme vous le feriez normalement pour installer une bibliothèque en Python, et virtuel sans faire quelque chose comme bundle exec ruby``. Le python de l'environnement peut importer les bibliothèques installées.
Désormais, la grande différence avec le bundle exec de Ruby est que la version Python de l'environnement virtuel est déterminée lorsque vous créez l'environnement virtuel, il suffit donc de spécifier la version de Python à utiliser une seule fois lors de la création de l'environnement virtuel. .. Cela signifie que vous n'avez pas à configurer `` pyenv local '' pour utiliser la même version de Python à chaque fois. [^ 2]
[^ 2]: Je pense que cette différence est la raison pour laquelle il y a tant d'opinions négatives sur pyenv à propos de "Y a-t-il un mérite d'apporter de la magie à la coquille et de la ralentir?"
Il existe plusieurs façons de spécifier temporairement la version Python uniquement lors de la création d'un environnement virtuel.
$ pyenv shell 3.6.1
$ python -m venv venv
$ pyenv shell --unset
(Ou)
$ `pyenv root`/versions/3.6.1/bin/python -m venv venv
[^ 1]: J'ai l'option pip install --target ou pip install --prefix, mais il n'y a pas de commande équivalente à bundle exec et je possède PYTHONPATH Doit être installé. Je ne le recommande pas car ce n'est pas une pratique très courante.
Les environnements virtuels créés avec venv peuvent être "activés". "activate" ajoutera le répertoire bin de l'environnement virtuel au début de la variable d'environnement PATH, afin que vous puissiez exécuter la commande comme pip au lieu de venv / bin / pip.
La variable d'environnement VIRTUAL_ENV est également définie. Le plug-in de complétion de Vim pour Python etc. examine cette variable d'environnement et exécute la complétion de méthode pour la bibliothèque importée.
$ . venv/bin/activate #Activez l'environnement virtuel
$ echo $VIRTUAL_ENV
/Users/inada-n/tmp/venv
$ which python
/Users/inada-n/tmp/venv/bin/python
$ which pip
/Users/inada-n/tmp/venv/bin/pip
$ deactivate #Commande pour activer activer
$ which python
/Users/inada-n/pyenv/shims/python
pyenv-virtualenv est un outil de gestion d'environnements virtuels utilisant les fonctions de pyenv. Il présente les avantages suivants.
Cependant, il y a une mise en garde concernant ce numéro 3. rbenv, pyenv, etc. utilisent un mécanisme appelé shims pour utiliser correctement plusieurs versions (y compris les environnements virtuels).
Pour expliquer grossièrement les shims, rassemblez les noms de commande sous le répertoire bin / de toutes les versions, et préparez un script shell avec le même nom dans $ PYENV_ROOT / shims. Le script shell est censé exécuter le nom de la commande pyenv exec.
La gestion de l'environnement virtuel avec ce mécanisme signifie que les commandes de l'environnement virtuel, telles que celles exécutées avec le nom de commande d'exec de bundle '' dans Bundler, entreront également des shims et seront accessibles dans le PATH. C'est. Les commandes fournies par les bibliothèques installées uniquement dans un environnement virtuel pour un projet existent toujours dans le PATH, apparaissent dans l'achèvement de la touche TAB et provoquent une erreur lors de l'exécution. (Par exemple, pyenv: pygmentize: command not found '').
En d'autres termes, la commodité de pyenv-virtualenv se fait au prix de "les commandes de l'environnement de quarantaine polluent le PATH global". Cependant, si vous faites `` pyenv uninstall virtual environment name '', les commandes qui sont uniques à cet environnement virtuel seront supprimées des shims, il est donc tout à fait possible d'arrêter progressivement pyenv-virtualenv après que les inconvénients deviennent réellement un problème. Donc je ne pense pas que vous ayez besoin d'avoir si peur.
Voici une brève introduction aux outils alternatifs que vous pouvez utiliser si vous n'utilisez pas pyenv-virtualenv. Veuillez rechercher séparément l'utilisation spécifique de chaque outil.
direnv est un outil qui vous permet de personnaliser les variables d'environnement lorsque vous entrez et sortez du répertoire de votre projet.
Vous pouvez remplacer la dernière des fonctions «gestion d'environnement virtuel» et «activation automatique» fournies par pyenv-virtualenv. Par exemple, si vous écrivez dans .envrc comme suit, il activera automatiquement l'environnement virtuel appelé venv dans ce répertoire.
.envrc
source venv/bin/activate
Non limité à Python, il est pratique pour les développeurs Go de l'utiliser à des fins générales, telles que la modification du GOPATH pour chaque projet.
Le premier choix est d'utiliser venv directement comme décrit ci-dessus («Différences entre Bundler et venv») sans utiliser les outils de gestion d'environnement virtuel tels que virtualenvwrapper et pew décrits ci-dessous.
C'est le plus proche de la convivialité de rbenv + Bundler, donc je pense que c'est facile à comprendre. Si vous avez besoin d'une activation automatique de votre environnement virtuel, vous pouvez utiliser le direnv présenté ci-dessus.
Malheureusement, par rapport à Bundler, il n'y a pas de normes ou de normes de facto pour les noms de répertoires d'environnements virtuels tels que vendeur / bundle ou node_modules. Vous ou votre équipe devez décider lequel utiliser, tel que «venv», «.venv», «vendor / venv».
virtualenvwrapper est un outil de gestion d'environnement virtuel qui a longtemps été utilisé par les grands développeurs Python.
Vous pouvez créer, supprimer ou activer un environnement virtuel dans le répertoire spécifié par la variable d'environnement WORKON_HOME (ou `$ HOME / .virtualenvs si non spécifié).
pew est similaire à virtualenvwrapper, mais utilise sa propre implémentation plutôt que la commande fournie par venv pour activer l'environnement virtuel. Plus précisément, au lieu de personnaliser le shell actuel, exécutez le shell personnalisé en tant que processus enfant. Vous pouvez revenir à l'environnement d'origine en fermant le shell enfant avec Ctrl-D au lieu de la commande `` désactiver ''.
Si vous installez pew, un outil appelé pythonz, qui construit et gère plusieurs versions de Python en conflit avec pyenv, sera installé en tant que dépendance, mais comme la mise à jour est plus lente que pyenv, vous pouvez utiliser pyenv sans vous en soucier. pense.
Un nouvel outil facile à utiliser comme Bundler. Au lieu du fichier d'exigences utilisé par pip, gérez la bibliothèque à l'aide d'un fichier basé sur TOML plus sophistiqué appelé Pipfile. Notez que Pipfile est toujours un outil expérimental et que le format peut changer à l'avenir, vous devez donc vous y préparer. (Je ne pense pas que ça change si souvent)
Par défaut, pew est utilisé pour gérer l'environnement virtuel, mais si vous définissez `` PIPENV_VENV_IN_PROJECT = true '' et la variable d'environnement, le répertoire .venv sous le projet sera utilisé, donc plus de Bundler Je pense que ce sera plus proche de la convivialité.
Si vous ne souhaitez pas utiliser la fonction de changement de version de pyenv telle que pyenv local, vous pouvez trouver `ʻecho'eval" dans instructions d'installation de pyenv. Vous pouvez alléger le shell et ne pas utiliser de shims en omettant "$ (pyenv init -)" '>> ~ / .bash_profile. Si vous omettez cette étape, pyenv install '', pyenv uninstall '', pyenv versions '' fonctionnera correctement.
Au lieu de `` pyenv global '', c'est une bonne idée d'aller directement dans votre PATH pour votre version Python habituelle.
$ echo 'export PATH=$PYENV_ROOT/versions/3.6.1/bin:${PATH}' >> ~/.bash_profile
Si vous êtes accro, vous pouvez faire de votre Python ordinaire un environnement virtuel pour garder le Python construit par pyenv propre.
$ $PYENV_ROOT/versions/3.6.1/bin/python -m venv ~/local/python-default
$ echo 'export PATH=$HOME/local/python-default/bin:${PATH}' >> ~/.bash_profile
Recommended Posts