Miniconda einrichten auf Linux

[say_hello]

Guten Morgen,


auf einem Linux-system will ich vscode und miniconda aufsetzen.

in einem Manual hab ich eine Anleitung gefunden -: https://engineeringfordatascience.com/p ... mand_line/

Diese wägt auch nochmals die diversen Vor und Nachteile ab - und vergleicht Anaconda u. Miniconda:

I would always recommend using Miniconda. Anaconda is very bloated and contains many libraries which you are unlikely to use, especially not in a single project. Given installing a library is only a ‘pip install’ away, it is easy to use Miniconda and only install libraries as and when you need them. I also believe it is better practice to make sure your environment is as ‘lean’ as possible, containing only the packages your project directly depends on.
There are alternative package managers for Python instead of Conda. Personally, I prefer to use pyenv for managing my python environments. It is lightweight, portable, simple to use and I also find pyenv has fewer ‘gotchas’ than conda. However, sometimes you do not have the luxury of choosing your preferred environment manager. For example, if your project requires a version of a Python library only available from conda-forge , or if your team prefer using a specific package manager for consistency.
It is always a good idea to be comfortable with multiple different package managers so you are flexible to your team’s or project requirements.

und der Autor fährt fort: Why Use the Command-Line?

in dem er einige Vorteile erläutert:

Installing Miniconda from the command line opens the door for automation.: Automating the set-up of your development environment is a key part of becoming an effective programmer. Automation provides the following direct and indirect benefits:

im Einzelnen:

Seamlessly move across different machines – get up and running quickly when working on a new machine, such as spinning up a Cloud VM or a new company laptop, instead of manually trying to install software
Consistency – running the same script to install software on different computers will ensure you are running a consistent environment and help to avoid errors when installing the software
Reproducibility – share your scripts with co-workers to ensure you are both working from the same environment (Dockerfiles are also a good option)
‘Clean Slate’ – when you inevitably accidentally break your environment (I am very guilty of this), you can easily remove everything and reinstall to restore the original state

Also das letzte Argument finde ich sehr einleuchtend bzw. attraktiv - den ich glaube dass es ja auch zu diversen Abhängikeiten u. Fallen kommen kann - u. man sehr gut mit venv, pyvenv etc. etx umgehen können muss um nicht in eine "Abhängigkeits-Hölle" zu geraten.

btw: der Autor empfiehlt den Einsatz von pyenv -

There are alternative package managers for Python instead of Conda. Personally, I prefer to use pyenv for managing my python environments. It is lightweight, portable, simple to use and I also find pyenv has fewer ‘gotchas’ than conda.

Ist denn - wenn man so ansetzt - es besonders aufwändig - dann auch

a. spyder und
b. vscode in dieses Setup noch mit einzubinden.

Viele Fragen auf einmal - sorry wenn die alle aufs Mal kommen u. ggf. etwas viel für einen einzigen Thread sein könnten.

VG

what would you recommend!?

[__deets__]

Unter Linux würde ich kein conda benutzen. Dessen Stärke liegt auf Windows, weil man da die ganzen Pakete schwerer bekommt. Unter Linux ist das dank verfügbarer Compiler weniger bis irrelevant.

Wie man VSCode etc damit integriert - keine Ahnung. Benutze emacs.

[say_hello]

hi Deets

vielen Dank für deine schnelle Antwort.

Klar - Python: das ist unter Linux im Grunde wesentlich einfach, (wenn) bzw. weil das alles korrekt über die Paketverwaltung installiert wird.

Aber: Muss man sich dann da nicht voll gut auskennen mit pip und venv - Pyenv - um nicht in Turbulenzen zu kommen

Deine Argumente - die sind im Grunde schon einleuchtend Für Linux emfehlen nicht viele Conda et al: allenfalls empfehlen viele wie du unter Windows Anaconda (bzw. MiniConda) zu nutzen.

Muss ggf. einfach mal unter Linux das einrichten - und VSCode dazu in das Setup einbinden. und gucken wie ich dann halt zurecht komme mit pip und venv bzw pyenv -


Dir nochmals Danke!

[say_hello]

Hi Deets, also Dir nochmals Danke!

update: - also wenn ich das mal in Linux angehe und einfach auf Anaconda u. Conda verzichte - dann sollte das ggf einfach so gehen dass ich Python ( eh nativ in Linux ) aktiviere - und VSCode (oder Codium) noch auf den Rechner draufbaue

.....und dann muss ich halt mit pip, pyenv oder venv mich auseinandersetzen

Managing Multiple Python Versions With pyenv
https://realpython.com/intro-to-pyenv/

How Can You Work With a Python Virtual Environment? von Martin Breuss
https://realpython.com/python-virtual-e ... -a-primer/


Denk halt dass das mit dem Einrichten des venv-Modul echt ein wichtiger Schritt ist - denn ich muss halt eine neue virtuelle Umgebung erstellen; - fragt sich was hier am zweckmässigsten ist venv pyenv usw. usf?!
Ich denke dass es jedenfalls so ist: Python erstellt eine eigenständige Ordnerstruktur und kopiert bzw symbolisiert die ausführbaren Python-Dateien in diese Ordnerstruktur. Ein Ordner für virtuelle Umgebungen enthält viele Dateien und Ordner, aber Sie werden vielleicht feststellen, dass das meiste, was diese Baumstruktur so lang macht, im Ordner site-packages/ liegt.

Martin Breuss meint das in dem og. Artikel so:

Code: Alles auswählen

venv\
│
├── Include\
│
├── Lib\
│   │
│   └── site-packages\
│       │
│       ├── _distutils_hack\
│       │
│       ├── pip\
│       │
│       ├── pip-22.0.4.dist-info\
│       │
│       ├── pkg_resources\
│       │
│       ├── setuptools\
│       │
│       ├── setuptools-58.1.0.dist-info\
│       │
│       └── distutils-precedence.pth
│
│
├── Scripts\
│   ├── Activate.ps1
│   ├── activate
│   ├── activate.bat
│   ├── deactivate.bat
│   ├── pip.exe
│   ├── pip3.10.exe
│   ├── pip3.exe
│   ├── python.exe
│   └── pythonw.exe
│
└── pyvenv.cfg

vgl. Breuss https://realpython.com/python-virtual-e ... -a-primer/

und vereinfacht dann so die reduzierte Baumstruktur im virtual environment-Ordner:

- Include\ is an initially empty folder that Python uses to include C header files for packages you might install that depend on C extensions.
- Lib\ contains the site-packages\ folder, which is one of the main reasons for creating your virtual environment. This folder is where you’ll install external packages that you want to use within your virtual environment. By default, your virtual environment comes preinstalled with two dependencies, pip and setuptools. You’ll learn more about them in a bit.
- Scripts\ contains the executable files of your virtual environment. Most notable are the Python interpreter (python.exe), the pip executable (pip.exe), and the activation script for your virtual environment, which comes in a couple of different flavors to allow you to work with different shells. In this tutorial, you’ve used activate, which handles the activation of your virtual environment for Windows across most shells.
- pyvenv.cfg is a crucial file for your virtual environment. It contains only a couple of key-value pairs that Python uses to set variables in the sys module that determine which Python interpreter and which site-packages directory the current Python session will use. You’ll learn more about the settings in this file when you read about how a virtual environment works.

vgl. Breuss https://realpython.com/python-virtual-e ... -a-primer/


hmm - Ich muss mir um die ganz oben gezeigte Baumstruktur keinen Kopp machen - sondern kann einfach mit pyenv oder venv das anlegen.
und dann muss ich halt noch den VSCode /oder Codium ins Setup einbinden...


Wie das Ganze Umsetzen;

Um mal das Ganze wie es dann werden sollte, kurz hier mit Euch zu besprechen:

Ich glaub dass ich das dann ggf. zum Beispiel etwa mit dem Program virtualenv mache sollte, mit dem ich mir die einzelnen Umgebungen einrichten kann. Ich hoffe halt, dass es z.B. das Paket python3-virtualenv gibt, das ich installieren kann ( ich bin unter a. MX-Linux - hab aber auch noch ein zweites Notebook mit EndeavourOS)

also ggf. sollte das dann so gehen:

Code: Alles auswählen

sudo dnf install python3-virtualenv

Damit bin ich schon fertig mit der Installation. Das Software-Paket sollte das Program virtualenv (eventuell mit angefügter Versionsnummer) enthalten, mit dem ich mir virtuelle Umgebungen für Python einrichten kann.

dann käme die Einrichtung: Jetzt habe ich die Software für die virtuellen Umgebungen; Nun käm es darauf an: wie verwende ich diese nun?

Ich sollte an diesem Schritt dann je eigene virtuelle Umgebung anlegen - also pro Projekt muss ich das im Grunde eigentlich ja nur einmal tun - lege ich eine virtuelle Umgebung an. Ich bewege mich in das Projektverzeichnis und rufe virtuelenv mit dem Namen des Verzeichnisses auf, in dem die Bibliotheken der virtuellen Umgebung abgelegt werden sollen.

Code: Alles auswählen

cd $project
virtualenv venv

Dieses Verzeichns nenne ich meist venv und zwar aus einem guten Grund, der beim Weiterlesen gleich klar wird.
Die virtuelle Umgebung aktivieren: Jedesmal, wenn ich in meinem Objekt mit der virtuellen Umgebung arbeiten will, muss ich diese aktivieren. Das allerdings nur einmal, bevor ich anfange zu arbeiten.

Code: Alles auswählen

cd $project
source venv/bin/activate 

geht auch über ne bash alias:

Code: Alles auswählen

alias venv_activate='source venv/bin/activate'

Dieser Alias ist nicht soviel kürzer als der eigentliche Befehl.

Hmm - also ggf. mach ich das dann so - und am Ende sieht das dann ggf. so aus.

Code: Alles auswählen

+------------------------+
|                        |
|                        |
|     python-workspace   |
|     ....-folder        |
|                        |
+----------+-------------+
           |
           |
           |              +----------------------+
           |              |                      |
           +--------------+     Project1         |
           |              |                      |
           |              +----------------------+
           |
           |              +----------------------+
           |              |                      |
           +--------------+     Project2         |
           |              |                      |
           |              +----------------------+
           |
           |              +----------------------+
           |              |                      |
           +--------------+     Project3         |
           |              |                      |
           |              +----------------------+
           |
           |              +----------------------+
           |              |                      |
           +--------------+     Project4         |
           |              |                      |
           |              +----------------------+
           |
           |              +----------------------+
           |              |                      |
           +--------------+    Project5          |
           |              |                      |
           |              +----------------------+
           |
           |              +----------------------+
           |              |                      |
           +--------------+   Project6           |
                          |                      |
                          +----------------------+

Hmm - ich denk ich sollte das ggf. einfach so machen. Und mal für den Anfang auf Conda verzichten - zuimindest auf der Linux-Kiste

Mal gucken - was auf jeden Fall noch offen ist, das ist die FRAGE wie gut ich hier dann VSCode /(Codium) oder eine andere Editor /resp IDE hier noch dazu konfiguriere.
Denke dass es ggf einfach am besten mit VSCodium geht - denn der ist ja weit verbereitet u. wohl auch gut dokumentiert...!?

Was meint ihr -sollt ich das so wie oben beschrieben angehen!?

[__deets__]

Klingt soweit ok. Persoenlich habe ich mich ferngehalten von pyenv, weil mir das zuviel Probleme beim Versuch, ein *neues Python pro Projekt zu bauen* produziert hat. Ich benutze desweiteren pipenv fuer das management der venvs. Das hat Vor- aber auch Nachteile - ein Nachteil ganz klar: man muss im Verzeichnis stehen, um mit "pipenv shell" oder "pipenv run" auf das venv zu referenzieren. Aber es erspart dir damit das ganze Geraffel, deine eigenen Kommandos anzulegen.

Zur Integration kann ich immer noch nichts sagen. Musst du recherchieren.

[say_hello]

hallo __deets__
vielen Dank für deine Rückmeldung - das ist sehr hilifreich - und ermutigend - (sich halt mal ohne [Ana] Conda auf dem Linux-Notebook aufs Native einzulassen.
Danke auch für deine Tipps u. geteilten Erfahrungen bzgl. pipenv u. wie du das machst.

Bei der Integration von VSCode guck ich nochmals nach Manuals .

VG u. allen einen schönen Mittag