wake-up-neo.net

Anaconda kann ohne ** Standardumgebung installiert werden?

Hintergrund

Ich möchte vermeiden, dass "versehentlich" in einer Standardumgebung gearbeitet wird.

Ich möchte immer ein Äquivalent zu einer requirements.txt- oder package.json-Datei verfügbar haben, sowohl um ein Projekt klar von einem anderen zu trennen, als auch, dass ich leicht nachschauen kann, was installiert ist (und welche Version davon).


Ich arbeite jedoch hauptsächlich in der Welt der Datenwissenschaft/Analytik und hauptsächlich mit Python.

Als solches benutze ich Anaconda , pip und Homebrew (ich habe einen Mac). Es wäre toll, auf nur einen Paketmanager angewiesen, und viele Leute befürworten eine Methode oder eine andere , um dies zu erreichen. Die Wahrheit ist, ab jetzt (September 2018) ist es unmöglich, in jeder Breite von Themen zu arbeiten und zumindest eine gewisse Mischung zu vermeiden.


Wenn ich meine Ziele niedriger und realistischer ansehe, möchte ich einfach sicherstellen, dass keine Standardumgebung vorhanden ist, wo immer dies möglich ist, um die Arbeit an Projekten mit anderen sauberer und einfacher zu gestalten.

Meines Wissens gibt es in Homebrew überhaupt keine Vorstellung von einer Umgebung. Conda hat natürlich Umgebungen, aber es richtet zuerst eine Standardumgebung ein, bevor Sie andere erstellen können.

Frage

Gibt es eine Möglichkeit, Anaconda ohne Standardumgebung zu installieren, sodass ich immer source activate <my_env> muss? Wenn ja, wie mache ich das?

Abgesehen davon, was sind die besten Vorschläge, um das zu erreichen, was ich will, nämlich niemals versehentlich in einer Umgebung zu arbeiten, in der unklar ist, was meine Abhängigkeiten sind, wobei ich erkenne, dass ich hauptsächlich, aber nicht ausschließlich über die Verwendung von Python spreche?

(Bitte schlagen Sie nicht vor, dass ich beim Installieren von Paketen "nur vorsichtig sein" sollte. Ja, das verstehe ich. Aber ich versuche vorbeugend zu sein, indem ich falsche Entscheidungen so schwierig oder unmöglich mache wie ich kann. Wenn ich es hätte Keine Standardumgebung, zum Beispiel würde pip erst funktionieren, wenn ich eine Umgebung beschafft habe, da sie in meiner normalen Umgebung nicht gefunden wird.)

7
Mike Williamson

Ich denke, Ihre beste Wette ist, einfach eine virtuelle Umgebung zu verwenden und Abhängigkeiten zu installieren, wenn diese notwendig werden. Dann können Sie Ihre virtuelle Umgebung einfach ein- und auschecken, wenn Ihre Arbeit voranschreitet. Sie können verschiedene virtuelle Umgebungen erstellen, während Sie an verschiedenen Projekten arbeiten, und die entsprechenden Datei Requirements.txt im Verzeichnis belassen, das Python bei der Installation einer virtuellen Umgebung erstellt. Nehmen wir an, ich habe Python3.5.2 als normales Go-To-Python-Paket (weil ich das mache). 

Mit python3.5 betreten wir eine virtuelle Umgebung mit nichts weiter als bloßem Knochen python3.5 (keine installierten Abhängigkeiten). Um dies zu tun:

[[email protected] venv_test]$ python -m venv my_SO_project
[[email protected] venv_test]$ ls
my_SO_project

wir sehen also, dass Python ein Verzeichnis für meine virtuelle Umgebung erstellt hat, aber meine virtuelle Umgebung wird nicht als Standard-Python verwendet. Dazu müssen wir es aktivieren:

[[email protected] venv_test]$ source ./my_SO_project/bin/activate

So sieht meine Shell jetzt so aus:

(my_SO_project) [[email protected]  venv_test]$

Wenn wir hier sind, schauen wir uns an, wie unsere Anforderungen aussehen:

(my_SO_project) [[email protected]  venv_test]$ pip freeze > requirements.txt
(my_SO_project) [[email protected]  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

Die Verwendung von Leerzeichen zum Ausblenden von Gruppennamen, aber wie wir sehen können, ist die Dateigröße von Requirements.txt leer. Dies bedeutet, dass diese virtuelle Umgebung keine Abhängigkeiten hat. Es ist rein Python3.5. Nun wollen wir Pandas installieren und sehen, wie sich unsere Abhängigkeiten ändern. 

(my_SO_project) [[email protected]  venv_test]$ pip install pandas
(my_SO_project) [[email protected]  venv_test]$ pip freeze > requirements.txt
(my_SO_project) [[email protected]  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) [[email protected]  venv_test]$ wc -l requirements.txt
5 requirements.txt

Nehmen wir an, wir haben etwas Code in die Umgebung geschrieben, und wir möchten keine weiteren Arbeiten mehr machen, also machen wir ein letztes Pip-Freeze> Requirements.txt und gehen:

(my_SO_project) [[email protected]  venv_test]$ deactivate
[[email protected]  venv_test]$ pip freeze > requirements_normal.txt
[[email protected]  venv_test]$ wc -l requirements_normal.txt
82 requirements_normal.txt

Es entstanden viel mehr Abhängigkeiten, aber in unserer normalen Umgebung hat sich nichts geändert, und in unserer virtuellen Umgebung hat sich nichts geändert. Nehmen wir an, wir haben den Rest des Tages frei genommen und möchten zu unserem SO_Projekt zurückkehren, das wir gestern erstellt haben. Nun, es ist einfach:

[[email protected]  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
[[email protected]  venv_test]$ source ./my_SO_project/bin/activate
(my_SO_project) [[email protected]  venv_test]$ 

Mal sehen, wo wir aufgehört haben (wir sollten nur Pandas installieren, überschreiben wir unsere alte Anforderungsdatei):

(my_SO_project) [[email protected]  venv_test]$ pip freeze > requirements.txt
(my_SO_project) [[email protected]  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, also wissen wir jetzt, wo wir aufgehört haben. Nur eine faire Warnung, ich habe Pandas auf meinem Root-Python-Paket installiert, aber was ich nicht habe, ist das awscli (Amazon Web Services Command Line Interface). Nehmen wir an, ich möchte das aus irgendeinem Grund in meinem Paket haben:

(my_SO_project) [[email protected]  venv_test]$ pip install awscli
(my_SO_project) [[email protected]  venv_test]$ pip freeze > requirements.txt
(my_SO_project) [[email protected]  venv_test]$ wc -l requirements.txt
15 requirements.txt
(my_SO_project) [[email protected]  venv_test]$ deactivate
[[email protected]  venv_test]$ ls
my_SO_project  requirements.txt  requirements_normal.txt
[[email protected]  venv_test]$ pip freeze > requirements_normal.txt
[[email protected]01  venv_test]$ wc -l requirements_normal.txt
82 requirements_normal.txt

Nun sehen wir nun, dass die Installation von awscli an unserem Python-Paket keine Änderung vorgenommen hat, jedoch für unser Programm:

[[email protected]  venv_test]$ more requirements_normal.txt
appdirs==1.4.3
arrow==0.7.0
attrdict==2.0.0
avro-cwl==1.8.4
...
[[email protected]  venv_test]$ more requirements.txt
awscli==1.16.29
botocore==1.12.19
colorama==0.3.9
docutils==0.14
...

Nehmen wir an, Sie haben ein super cooles Data-Science-Paket entwickelt, das vollständig in Ihrem VM enthalten ist, und Sie haben es für die Installation als pip-fähig eingerichtet. Das geht schnell und einfach:

[[email protected]  venv_test]$ pip install -r requirements.txt

Sie können diese jetzt als Paketliste verwenden, wenn Ihr neues Programm installiert wird. Außerdem kennen Sie jedes Python-Paket, das Sie dafür benötigen, da dies die einzigen sind, die Sie in Ihre Umgebung aufgenommen haben.

Alles in allem gibt es keinen Grund, dass Sie dies nicht jedes Mal tun können, wenn Sie ein neues Projekt mit neuen Leuten beginnen. Wenn Sie Anaconda in jeder virtuellen Umgebung haben möchten, die Sie jemals verwenden, installieren Sie Anaconda normal:

[[email protected]  venv_test]$ ./Anaconda-1.6.0-Linux-x86_64.sh
[[email protected]  venv_test]$ source /home/dkennetz/anaconda3/bin/activate
#You will be in your anaconda environment now
(base) [[email protected]  venv_test]$ pip freeze > anaconda_reqs.txt

Angenommen, Sie haben my_SO_project2 jetzt nach dem ersten gestartet und möchten sicherstellen, dass Sie Anaconda in diesem Paket haben. erstellen sie ihr neues venv auf die gleiche weise wie beim letzten mal. Wenn Sie erst einmal drin sind, installieren Sie alle Abhängigkeiten, die Anaconda benötigt, und Sie haben eine neue virtuelle Anaconda-Umgebung:

(my_SO_project2) [[email protected]  venv_test]$ pip install -r anaconda_reqs.txt

Ihre neue Küche beginnt mit einer frischen Umgebung, in der nur Anaconda installiert ist.

Ich hoffe, das klärt, was ich in den Kommentaren gesagt habe, und es ist hilfreich für Sie.

2
d_kennetz

Zuerst würde ich Python entfernen von meinem System entfernen.

Edit: Wie in den Kommentaren darauf hingewiesen, ist dies bei Macos keine gute Idee. Ich würde diesen Ansatz nur in einem Docker-Container verwenden. Aber wenn Sie Docker haben, können Sie pro Projekt ein Projekt erstellen, und Sie sind festgelegt.

Der Befehl which python sollte nichts zurückgeben.

Installiere miniconda das ist der Conda-Paketmanager zusammen mit Bare Python.

Erstellen Sie eine Umgebung pro Projekt

conda create -n myproject python=3.6

Da es kein Standard-Python gibt, müssen Sie need eine Umgebung als Quelle verwenden, wenn Sie darin arbeiten möchten

source activate myproject

Beachten Sie, dass Miniconda technisch eine Standardumgebung namens "base" erstellt (diese kann nicht entfernt werden). Aber wie bei allen anderen Envs ist es nicht aktiviert, so dass Sie immer noch keinen Python haben (wenn Sie ihn wie vorgeschlagen entfernen) und den "falschen" Python nicht versehentlich ausführen können.

2