Genopbyg Python-miljøer med venv og pip på en dokumenterbar måde

Når et lille kontor overtager en Python-applikation eller sætter en computer op på ny, bør applikationens pakkesammensætning være dokumenteret. Med venv og pip kan man forberede en kontrolleret genopbygning. Det afgørende er et rent udgangsmiljø, kontrollerede afhængigheder og applikationstest. En pakkeeksport alene garanterer ikke universel reproducerbarhed.

1. Fastlæg forudsætninger og arbejdsmappe

Alle de følgende Unix-eksempler må udelukkende bruges i et separat testprojekt, ikke i applikationens produktionsmappe. Forudsætningen er en allerede installeret og vedligeholdt Python-fortolker, som er kompatibel med projektet. Dokumentér på forhånd:

den tilsigtede fortolkerversion inklusive underversion,
operativsystem og processorarkitektur,
projektets aktuelle tilstand, den nødvendige konfiguration og de tilgængelige applikationstest.

python3 betegner her denne bevidst valgte fortolker. Kontrollér, hvilken fortolker kommandoen henviser til, før du begynder; brug om nødvendigt den eksplicitte sti til fortolkeren. Udskift ikke operativsystemets Python, og ændr ikke den globale PATH. Alle relative stier tager udgangspunkt i testprojektets rodmappe. Filnavne som requirements-snapshot.txt er frit valgte eksempler og skal ved ændringer tilpasses konsekvent overalt.

2. Forbered et rent kildemiljø

Opret et særskilt miljø, der som udgangspunkt er rent, til den tilsigtede projekttilstand:

python3 -m venv .venv-src

Installér udelukkende de afhængigheder, der er beregnet til testprojektet, i dette miljø, og følg projektets installationsvejledning. Brug eksplicit .venv-src/bin/python -m pip, så du ikke ved en fejl bruger et andet miljø. Overtag ikke en ukontrolleret samling fra et fælles arbejdsmiljø, og foretag ikke generelle opgraderinger af alle pakker.

Ifølge dokumentationen til venv er projektpakker som standard isolerede. Miljøet er dog fortsat bundet til sin basisfortolker og er ikke en sikkerhedssandkasse. Aktivering er ikke nødvendig, når der bruges eksplicitte stier til fortolkeren. Test nu applikationen med egnede testdata; først derefter foretages eksporten.

3. Registrér og kontrollér den testede pakkesammensætning

.venv-src/bin/python -m pip freeze > requirements-snapshot.txt

pip freeze viser installerede pakker. Det er ikke et værktøj, der løser afhængigheder og opretter en låsefil, og det udelader som standard visse bootstrap-pakker. Filen er derfor et indledende øjebliksbillede, ikke en fuldstændig beskrivelse af fortolker, værktøjer og platform.

Åbn eksportfilen, hver gang den skal deles med andre. Kontrollér især redigerbare installationer, lokale stier og private pakke-URL’er. Fjern adgangsoplysninger fra filer, der deles. Afklar samtidig, hvordan der fortsat kan opnås autoriseret adgang til nødvendige private pakker; blot at slette sådanne poster gør ikke genopbygningen fuldstændig. Registrér direkte og transitive afhængigheder i stedet for kun at angive de biblioteker, der bruges direkte.

4. Genopbyg uafhængigt, og verificér

Lad .venv-src forblive uændret. Opret ved siden af det et andet miljø med en passende, kompatibel fortolker, og installér den kontrollerede liste:

python3 -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip install -r requirements-snapshot.txt
.venv-rebuild/bin/python -m pip check

pip check kontrollerer udelukkende kompatibiliteten mellem de erklærede afhængigheder. Et resultat uden anmærkninger erstatter hverken applikationstest eller en sikkerhedsgennemgang. Udfør derfor de samme faglige kontroller som i kildemiljøet: eksempelvis en tilsigtet import, en typisk behandlingskørsel og kontrol af resultaterne. Start også disse kontroller eksplicit med .venv-rebuild/bin/python. Dokumentér fejl og testresultater, før du godkender genopbygningen.

5. Dokumentér platform og pakkefiler mere detaljeret

For at gøre forløbet lettere at efterspore skal du desuden registrere de anvendte versioner af Python og pip samt operativsystem og arkitektur. Ifølge pips vejledning til gentagelige installationer kan fuldt fastlagte direkte og transitive afhængigheder samt kontrollerede pakkehashværdier sikre processen yderligere. Hashværdier bekræfter, at pakkefilerne er de forventede, ikke at de er fri for skadelig software. Wheel-arkiver kan være platformspecifikke; en pakkesammensætning, der er tilgængelig på en anden arkitektur, er derfor ikke automatisk tilsvarende.

6. Sørg for en vej tilbage, og dokumentér resultatet

Behold det hidtidige miljø samt en sikkerhedskopi af applikationen og dataene, indtil det nye miljø er verificeret. Hvis der opstår fejl, skal du kun kassere det nye testmiljø og undersøge årsagen; det hidtidige arbejdsgrundlag forbliver urørt. Virtuelle miljøer oprettes på ny, de flyttes eller kopieres ikke.

Konklusion: En brugbar genopbygning består af en kontrolleret pakkeeksport, en dokumenteret platform og vellykkede applikationstest. Denne kombination gør ændringer sporbare uden at forveksle en pakkeliste med en omfattende garanti for reproducerbarhed.