- vorweg: das Thema ist Python-Pur und deshalb denke ich, dass ich das am besten hier rein-poste, Ich hoffe mal dass ich hiermit richtig liege.
virtualenv unter anaconda: was mich allerdings etwas wundert: Aber auch da wird ein virtualenv angeboten anaconda - es gibt sogar ein virtualenv plugin für pyenv.
Also vorweg schon mal die Frage zu pyenv und virtualenv: brauch ich die denn bei Anaconda denn gleich auch am Anfang - muss ich die miteinrichten oder eher nur bei (Mini).Conda! Ich hab mir die Tutorials angesehen und mich mal kurz eingelesen: bei der Installation von Anaconda in ein Win 10 sollte man aufpassen: Wenn python schon auf dem Rechner ist - dann kann es Abhängikeiten geben. Am allerbsesten ist es wenn mal noch nix auf der Maschine ist - also weder Python oder Conda oder Anaconda::
dennoch: immer und in jedem Falle wichtig und gut: dann nicht einfach durchklicken: x add anaconda to the system path environment wenn man schon ein.conda directory im home hat - dann ist das nicht weiter tragisch.
- Code: Select all
$ cd
$ mkdir -p .conda/pkgs/cache .conda/envs
Damit richtet man sich ein Python environment ein: Der conda create command führt genau diesen Schritt aus versehen mit einem python=version argument. Übrigens sind die package-manager in Anaconda und Miniconda glücklicherweise identisch (Conda), Man muss nicht Miniconda in das System installieren wenn man beabsichtigt, ohnehin bei Anaconda zu bleiben.
envs wird erzeugt mit dem Kommando:
- Code: Select all
conda create -n myenv python some_packages
Das klappt - allerdings kann es zu einer Ausnahme kommen - wenn verschiedene Pakete nebeneinander existieren und verschiedene package caches -
Bei Konflikten einfach eines loeschen und die shell initialization script (e.g., .bash_profile) cleanen - denn die Installer laufen auch darüber.
Hier nun eine Extra-Frage: was wenn ich ein Paket nicht über Conda finde
- Code: Select all
$ conda install --channel conda-forge ads
passend hierzu - ein snippet aus dem Web
- Code: Select all
Install from conda-forge
Add the conda-forge channel: conda config --add channels conda-forge.
Create a new environment containing SageMath: conda create -n sage sage python=X , where X is version of Python, e.g. 2.7.
Enter the new environment: conda activate sage
wenn man das package nicht über conda findet, kann man dann tatsächlich via Python packages wie "pip" weitermachen. Das bringt einem doch unweigerlich in die Abhängikeitsfalle - denn conda kennt doch dann die Abhängigkeiten nicht (mehr) wenn ich weitermache mit
- Code: Select all
"easy_install", oder
"python setup.py"
Wenn ich die conda-packages in einer Umgebung update, wo conda-packages mit anderen packaging-styles gemischt sind, bring ich mich dann doch in Abhänigkeiten. Ergo denke ich, dass man pip nur sehr zurückhaltend einsetzen sollte - und allenfalls dann - wenn man noch die "--user" option mitverwendet, sodass es dann ins Homeverzeichnis reininstalliert.
Grundsätzlich denke ich dass virtualenvs einfach im grunde genommen nichts dauerhaft statisches sind - sondern vielmehr auch vergänglich Und wenn es denn gar nicht anders geht - dann halt Abhaengigkeiten in das Projekt-Repository aufnehmen. Wenn venv nicht geht oder wenn es z.-B. kaputt/komisch/nicht-exisistent-auf-einem-neuen-Rechner ist, dann sollte man das neu anlegen. nicht also etwa zentrischer Ersatz fuer Container, VMs oder aehnliches. Um Abhängikeiten zu vermeiden mussm an natuerlich nachhalten, was man installiert hat, und in welcher Version (z.b. mit pipenv,pip hat requirements.txt, wobei conda etwas eigenes hat. Ich bin im Moment noch nicht reingelaufen in die Superprobleme - sondern hab ich auch vorab einfach mal mit dem moeglichen Abhängigkeiten ausinandergesetzt,. Dabei bin ich auf Hinweise gestoßen wie diesen; man sollte dann unter conda mit conda arbeiten - und nicht mit pip ...
https://stackoverflow.com/questions/20994716/what-is-the-difference-between-pip-and-conda
So Conda is a packaging tool and installer that aims to do more than what pip does; handle library dependencies outside of the Python packages as well as the Python packages themselves. Conda also creates a virtual environment, like virtualenv does. As such, Conda should be compared to Buildout perhaps, another tool that lets you handle both Python and non-Python installation tasks. Because Conda introduces a new packaging format, you cannot use pip and Conda interchangeably; pip cannot install the Conda package format. You can use the two tools side by side (by installing pip with conda install pip) but they do not interoperate either.
Darüber hinaus: Weil das Ganze mich dann doch so stark beschäftigt hat hab ich ein paar Cheatsheets rausgesucht. hier also Weitere '''Quellen: '''insgesamt hier noch mehr zum Thema Anaconda und weitere Quellen: insgesamt hier noch mehr zum Thema Anaconda und Conda: what-is-the-difference-between-pyenv-virtualenv-anaconda
vgl. https://stackoverflow.com/questions/38217545/what-is-the-difference-between-pyenv-virtualenv-anaconda
pip: the Python Package Manager.
pyenv: Python Version Manager
virtualenv: Python Environment Manager.
Anaconda: Package Manager + Environment Manager + Additional Scientific Libraries.
Conda cheat sheet https://medium.com/@buihuycuong/conda-cheat-sheet-f9424fa2e3f5
- Conda cheat sheet
- Command line package and environment manager
Managing Conda and Anaconda https://kapeli.com/cheat_sheets/Conda.docset/Contents/Resources/Documents/index
Managing Conda and Anaconda
Managing Environments
Managing Python
Managing .condarc Configuration
Managing Packages, Including Python
Removing Packages or Environments
conda-cheatsheet: http://know.continuum.io/rs/387-XNW-688/images/conda-cheatsheet.pdf
IInstallationsanleitung für Conda - in deutsch: https://uni-tuebingen.de/einrichtungen/zentrum-fuer-datenverarbeitung/dienstleistungen/serverdienste/computing/kompendium/python-pakete-installieren/
