Closed PhilTaken closed 8 months ago
Ich würde hier nochmal gucken, ob wir flake-parts und nix-filter wirklich brauchen, sonst sieht interessant aus. Welchen Kontext hat das, batou als nix python package zu packetieren? Das ganze ist dann ja Orthogonal zum workflow mit appenv, oder?
Das ganze ist dann ja Orthogonal zum workflow mit appenv, oder?
Ich würde das nicht ganz so unterschreiben. Einerseits muss das Batou verpackt werden für die devShell, um LSP completions etc zu erlauben, andererseits erlaubt das als Nebeneffekt halt auch die Nutzung vom Batou allein durch Flakes ohne appenv, was bestimmte appenv bugs wie das neu-erstellen der env bei jeder kleinen Änderung umgeht.
flake.parts ließe sich durchaus ersetzen, nix-filter kann man zur not auch mit vanilla nix selbst nachbauen, ob man das hier selbst machen will ist eine andere Frage
Ich meinte da jetzt Orthogonal im Sinne von Repo-Workflow. Aktuell pint man ja dependencies und auch die batou version mit requirements.txt Wenn man diese Implementation verwenden will ("die Nutzung vom Batou allein durch Flakes ohne appenv") macht man dann python dependencies über die Flake DevShell?
Habe ich das richtig verstanden?
Ja, für spezifische deployment Repos könnte man Batou dann über Flakes einspielen und würde die Deps dann nicht mehr über eine requirements.txt managen.
Wir hatten das im Team schon einmal kurz besprochen und hatten bisher nicht vor, Deployments zentriert um Nix Flakes umzubauen. Der bisherige und etablierte workflow mit der requirements.txt Datei würde von der Flake ja auch gar nicht beeinflusst werden.
Dass man es dann anders benutzen kann ist wie gesagt erst mal Nebeneffekt.
add a nix flake to batou to build the batou python package as well as a devshell for development purposes