Reproducible Dev Environments

[njoerd114]

Um sich auf eine einheitliche Entwicklungsumgebung verlassen zu können, wären reproducible Dev Environments wünschenswert, am liebsten devbox.sh

[lorenzleutgeb]

Eine weitere Möglichkeit wäre Nix, bzw. Nix via devenv.sh

[niklasbeinghaus]

das ist implizit, devbox geht nicht ohne Nix.

[lorenzleutgeb]

Für meinen Geschmack "zu implizit". Hätte angenommen, dass die Zeichenfolge "Nix" dann zumindest irgendwo auf devbox.sh vorkommt. Danke für den Hinweis.

[njoerd114]

hab fälschlicherweise auf deren cloud-angebot verwiesen, auf der eigentlichen Seite zum Produkt steht es: https://www.jetify.com/devbox

[danimo]

Danke für den Hinweis auf devbox.sh. Gleichzeitig möchte nur davor warnen, die Einstiegshürden mit zusätzlichen bzw. spezielleren Dependencies höher zu hängen. Der Vorteil an pip mit (ggf. mit direnv/lorri) ist seine Einfachheit und das Einzige, was es uns nicht zusichert ist die Python-Version. Solange wir nicht deutlich mehr notwendige Dependencies brauchen, die pip nicht liefern kann, würde ich die Hürden niedrig halten. Übersehe ich was?

[lorenzleutgeb]

AFAIK schließen sich die beiden Zugänge nicht aus. Nur weil es ein devbox/devenv/Nix Environment gibt, heißt das nicht, dass man nicht auch direkt pip verwenden kann, wenn man möchte.

[danimo]

Das stimmt schon, und es gibt schon jetzt "more than one way to do it", aber das kommt aktuell alles bei virtualenv/pip raus. Mir geht es nur darum, dass es am Ende hintenraus nicht zu sehr fragementiert. Ich werde mir devbox wie gesagt mal ansehen.

[dsiebel]

Habe über die letzten Jahre ganz gute Erfahrungen mit https://containers.dev/ gemacht.
Speziell mit VSCode und bereits existierendem container-setup (#11) deutlich anfängerfreundlicher als z.B. Nix.

[niklasbeinghaus]

genau die komplexität von nix wird durch devbox wegabstrahiert. wie @lorenzleutgeb schon erwähnt hat, ist das nur ein zusätzlicher weg, der die konfiguration (bspw. requirements.txt) einfach nutzt. Der große Vorteil ist imo, dass das setup portabel wird und user einfach nur devbox run server ausführen muss, alle dependencies aufgelöst werden, etc.

[niklasbeinghaus]

btw.

devcontainers können mit devbox generiert werden:
devbox generate devcontainer

[dvgitit]

devbox ggf. mit devcontainer finde ich ein gute Variante.

Empfehlenswert wäre, das Python Tooling zuvor auf uv umzustellen.

[niklasbeinghaus]

Das stimmt schon, und es gibt schon jetzt "more than one way to do it", aber das kommt aktuell alles bei virtualenv/pip raus. Mir geht es nur darum, dass es am Ende hintenraus nicht zu sehr fragementiert. Ich werde mir devbox wie gesagt mal ansehen.

Es kommt auch hier venv/pip bei raus, nur eben über devbox. Es erleichtert bspw. auch die Ausführung der Tests, siehe #159

[BerndCzech]

Danke für den Hinweis auf devbox.sh. Gleichzeitig möchte nur davor warnen, die Einstiegshürden mit zusätzlichen bzw. spezielleren Dependencies höher zu hängen. Der Vorteil an pip mit (ggf. mit direnv/lorri) ist seine Einfachheit und das Einzige, was es uns nicht zusichert ist die Python-Version. Solange wir nicht deutlich mehr notwendige Dependencies brauchen, die pip nicht liefern kann, würde ich die Hürden niedrig halten. Übersehe ich was?

@danimo - das habe ich auch gedacht - gleichzeitig läuft bei mir pip install -r requirements.txt auch nicht immer sauber durch. Was ich dann bisher immer gemacht habe, ist alles in einen Docker Container zu werfen.

Ich habe #159 ausprobiert und das ist super convenient. Imho hast du vielleicht noch eine (optionale, kleine) requirement am Anfang mehr skalierst aber langfristig besser.

[akokam]

You might want to have a look at poetry for dependency management as well as dependency pinning.

pro: it's well defined but you leave the actual dev env to the developer (if on local, in a container, mac, linux, windows, ...).

it works well in a container and ci/cd too!