Possible d'installer Anaconda sans ** aucun ** environnement par défaut?
Contexte
Je veux éviter de travailler "accidentellement" dans un environnement par défaut.
Je souhaite toujours disposer d'un équivalent d'un fichier requirements.txt ou package.json, à la fois pour séparer clairement un projet d'un autre et pour pouvoir facilement revenir en arrière pour voir ce qui est installé (et quelle version de celui-ci).
Mais je travaille principalement dans le monde de la science des données et de l’analyse, et principalement avec Python.
En tant que tel, j'utilise Anaconda , pip et Homebrew (j'ai un Mac). Ce serait formidable de compter sur un seul gestionnaire de paquets}, et de nombreuses personnes souscrivent à une méthode ou une autre pour accomplir cela. La vérité est, à partir de maintenant (septembre 2018), il est impossible de travailler dans une vaste gamme de sujets et d'éviter au moins un peu de mélange.
Mes objectifs plus bas et plus réalistes, je veux simplement m'assurer qu'il n'y a pas d'environnement par défaut dans la mesure du possible, afin de rendre le travail plus propre et plus facile avec d'autres.
À ma connaissance, il n’existe aucun concept d’environnement dans Homebrew. Bien sûr, Conda a des environnements, mais il configure d’abord un environnement par défaut avant de pouvoir en créer d’autres.
Question
Est-il possible d'installer Anaconda sans environnement par défaut , de sorte que je devrai toujours source activate <my_env>? Si oui, comment je fais ça?
En dehors de cela, quelles sont les meilleures suggestions pour accomplir ce que je veux, à savoir ne travaillez jamais accidentellement dans un environnement où les dépendances ne sont pas claires , reconnaissant que je parle principalement mais pas exclusivement d'utilisation Python?
(Merci de ne pas suggérer que je devrais "faire attention" lors de l'installation de paquets. Oui, je le comprends. Mais j'essaie de faire attention de manière préventive en faisant les mauvais choix aussi difficiles ou impossibles que possible. Si j'avais pas d’environnement par défaut, par exemple, alors pip ne fonctionnerait pas tant que je n’aurais pas créé un environnement, car celui-ci ne se trouverait pas dans mon environnement normal.)
Je pense que votre meilleur choix est simplement d’utiliser un environnement virtuel et d’installer les dépendances à mesure qu’elles deviennent nécessaires, puis d’archiver votre environnement virtuel au fur et à mesure que votre travail avance. Vous pouvez créer différents environnements virtuels à mesure que vous travaillez sur différents projets et conserver les fichiers Requests.txt correspondants dans le répertoire créé par python lors de l'installation d'un environnement virtuel. Disons que j'ai python3.5.2 comme paquet normal pour python (parce que je le fais).
En utilisant python3.5, entrons dans un environnement virtuel avec rien de plus que bare bones python3.5 (pas de dépendances installées). Pour faire ça:
[dkennetz@node venv_test]$ python -m venv my_SO_project
[dkennetz@node venv_test]$ ls
my_SO_project
nous voyons donc, python a créé un répertoire pour héberger mon environnement virtuel, mais mon environnement virtuel n'est pas utilisé comme mon python par défaut. Pour cela, il faut l'activer:
[dkennetz@node venv_test]$ source ./my_SO_project/bin/activate
Donc, ma coquille ressemble maintenant à ceci:
(my_SO_project) [dkennetz@nodecn201 venv_test]$
Pendant que nous sommes ici, voyons à quoi ressemblent nos exigences:
(my_SO_project) [dkennetz@nodecn201 venv_test]$ pip freeze > requirements.txt
(my_SO_project) [dkennetz@nodecn201 venv_test]$ ls -alh
drwxr-x--- 3 dkennetz blank 4.0K Oct 9 09:52 .
drwxr-x--- 93 dkennetz root 16K Oct 9 09:40 ..
drwxr-x--- 5 dkennetz blank 4.0K Oct 9 09:47 my_SO_project
-rwxr-x--- 1 dkennetz blank 0 Oct 9 09:47 requirements.txt
Utilisation de blancs pour masquer les noms de groupe, mais comme nous pouvons le constater, la taille de notre fichier exigences.txt est vide, ce qui signifie que cet environnement virtuel ne comporte aucune dépendance. C'est purement python3.5. Maintenant, allons-y, installons des pandas et voyons comment nos dépendances changent.
(my_SO_project) [dkennetz@nodecn201 venv_test]$ pip install pandas
(my_SO_project) [dkennetz@nodecn201 venv_test]$ pip freeze > requirements.txt
(my_SO_project) [dkennetz@nodecn201 venv_test]$ more requirements.txt
numpy==1.15.2
pandas==0.23.4
python-dateutil==2.7.3
pytz==2018.5
six==1.11.0
(my_SO_project) [dkennetz@nodecn201 venv_test]$ wc -l requirements.txt
5 requirements.txt
Supposons que nous ayons écrit du code dans l'environnement et que nous ne voulons plus faire de travail. Nous finissons donc par un gel final de pip> exigences.txt et nous partons:
(my_SO_project) [dkennetz@nodecn201 venv_test]$ deactivate
[dkennetz@nodecn201 venv_test]$ pip freeze > requirements_normal.txt
[dkennetz@nodecn201 venv_test]$ wc -l requirements_normal.txt
82 requirements_normal.txt
Beaucoup plus de dépendances sont apparues, mais rien n'a changé dans notre environnement normal et rien n'a changé dans notre environnement virtuel. Maintenant, disons que nous avons pris le reste de la journée et souhaitons revenir à notre projet SO_projet créé hier. Eh bien c'est facile:
[dkennetz@nodecn201 venv_test]$ ls -alh
drwxr-x--- 3 dkennetz blank 4.0K Oct 9 10:01 .
drwxr-x--- 93 dkennetz root 16K Oct 9 09:40 ..
drwxr-x--- 5 dkennetz blank 4.0K Oct 9 09:47 my_SO_project
-rwxr-x--- 1 dkennetz blank 77 Oct 9 09:56 requirements.txt
-rwxr-x--- 1 dkennetz blank 1.3K Oct 9 10:01 requirements_normal.txt
[dkennetz@nodecn201 venv_test]$ source ./my_SO_project/bin/activate
(my_SO_project) [dkennetz@nodecn201 venv_test]$
Voyons où nous en sommes restés (nous ne devrions avoir que des pandas installés, écrasons notre ancien fichier requirements_file):
(my_SO_project) [dkennetz@nodecn201 venv_test]$ pip freeze > requirements.txt
(my_SO_project) [dkennetz@nodecn201 venv_test]$ more requirements.txt
numpy==1.15.2
pandas==0.23.4
python-dateutil==2.7.3
pytz==2018.5
six==1.11.0
Cool, alors nous savons maintenant que nous en sommes là. Un avertissement juste, des pandas sont installés sur mon paquet root python, mais ce que je n’ai pas, c’est l’awscli (interface de ligne de commande des services Web d’Amazon). Disons que je le veux pour une raison quelconque dans mon paquet:
(my_SO_project) [dkennetz@nodecn201 venv_test]$ pip install awscli
(my_SO_project) [dkennetz@nodecn201 venv_test]$ pip freeze > requirements.txt
(my_SO_project) [dkennetz@nodecn201 venv_test]$ wc -l requirements.txt
15 requirements.txt
(my_SO_project) [dkennetz@nodecn201 venv_test]$ deactivate
[dkennetz@nodecn201 venv_test]$ ls
my_SO_project requirements.txt requirements_normal.txt
[dkennetz@nodecn201 venv_test]$ pip freeze > requirements_normal.txt
[dkennetz@nodecn201 venv_test]$ wc -l requirements_normal.txt
82 requirements_normal.txt
Nous voyons donc maintenant que l’installation de awscli n’a pas apporté de modification à notre paquet python, mais elle a pour principe:
[dkennetz@nodecn201 venv_test]$ more requirements_normal.txt
appdirs==1.4.3
arrow==0.7.0
attrdict==2.0.0
avro-cwl==1.8.4
...
[dkennetz@nodecn201 venv_test]$ more requirements.txt
awscli==1.16.29
botocore==1.12.19
colorama==0.3.9
docutils==0.14
...
Enfin, supposons que vous ayez développé un package de science de données super cool entièrement à l’intérieur de votre VM et que vous l’ayez rendu pip installable. Pour cela, il suffit simplement de:
[dkennetz@nodecn201 venv_test]$ pip install -r requirements.txt
Vous pouvez maintenant utiliser ceci comme liste de paquetages à chaque fois que votre "nouveau programme" est installé par pip. Mieux encore, vous connaissez tous les paquetages Python dont vous avez besoin car ce sont les seuls que vous avez inclus dans votre environnement.
Tout cela étant dit, il n'y a aucune raison pour que vous ne puissiez pas le faire chaque fois que vous démarrez un nouveau projet avec de nouvelles personnes. Et si vous voulez avoir anaconda dans tous les environnements virtuels que vous utilisez, installez normalement anaconda:
[dkennetz@nodecn201 venv_test]$ ./Anaconda-1.6.0-Linux-x86_64.sh
[dkennetz@nodecn201 venv_test]$ source /home/dkennetz/anaconda3/bin/activate
#You will be in your anaconda environment now
(base) [dkennetz@nodecn201 venv_test]$ pip freeze > anaconda_reqs.txt
Supposons que vous avez lancé my_SO_project2 maintenant après le premier et que vous souhaitez vous assurer que vous avez bien anaconda dans ce package. créez votre nouveau venv comme vous l’avez fait la dernière fois. Une fois à l'intérieur, installez toutes les dépendances requises par anaconda et vous obtiendrez un nouvel environnement virtuel:
(my_SO_project2) [dkennetz@nodecn201 venv_test]$ pip install -r anaconda_reqs.txt
Et votre nouveau site commence comme un environnement frais avec rien d’autre que l’anaconda installé.
J'espère que cela clarifie ce que j'ai dit dans les commentaires et que cela vous aidera.
D'abord je enlève python de mon système.
Edit: Comme indiqué dans les commentaires, ce n'est pas une bonne idée sous macos. J'utiliserais cette approche uniquement dans un conteneur Docker. Mais alors, si vous avez docker, vous pouvez en générer un par projet et vous êtes prêt.
La commande which python ne doit rien renvoyer.
Installez miniconda qui est le gestionnaire de paquets conda avec nu python.
Créer un environnement par projet
conda create -n myproject python=3.6
Comme il n’existe pas de Python par défaut, vous besoin sourcez un environnement chaque fois que vous souhaitez y travailler.
source activate myproject
Notez que techniquement, miniconda crée un env par défaut appelé "base" (il ne peut pas être supprimé). Mais comme toutes les autres env, il n'est pas activé, vous ne disposerez donc toujours pas de python (si vous avez supprimé comme indiqué) et ne pouvez pas exécuter accidentellement le "mauvais" python.