Gjenopprett Python-miljøer med venv og pip på en etterprøvbar måte

Når et lite kontor overtar en Python-applikasjon eller setter opp en datamaskin på nytt, bør det være mulig å etterprøve hvilke pakker applikasjonen bruker. Med venv og pip kan man forberede en kontrollert gjenoppretting. Et rent utgangsmiljø, kontrollerte avhengigheter og applikasjonstester er avgjørende. En pakkeeksport alene garanterer ikke universell reproduserbarhet.

1. Fastsett forutsetninger og arbeidskatalog

Alle Unix-eksemplene nedenfor skal utelukkende brukes i et separat testprosjekt, ikke i applikasjonskatalogen som brukes i produksjon. En forutsetning er en allerede installert og vedlikeholdt Python-tolk som er kompatibel med prosjektet. Dokumenter følgende på forhånd:

  • den tiltenkte tolkversjonen, inkludert underversjon,
  • operativsystem og prosessorarkitektur,
  • prosjektets tilstand, nødvendig konfigurasjon og tilgjengelige applikasjonstester.

python3 viser her til denne bevisst valgte tolken. Kontroller hvilken tolk kommandoen viser til før du begynner, og bruk om nødvendig den eksplisitte banen til tolken. Ikke erstatt operativsystemets Python, og ikke endre den globale PATH. Alle relative baner viser til rotkatalogen i testprosjektet. Filnavn som requirements-snapshot.txt er fritt valgte eksempelnavn og må tilpasses konsekvent dersom de endres.

2. Klargjør et rent kildemiljø

Opprett et eget miljø som i utgangspunktet er rent, for den tiltenkte prosjekttilstanden:

python3 -m venv .venv-src

Installer bare avhengighetene som er beregnet på testprosjektet, i henhold til prosjektets installasjonsveiledning. Bruk uttrykkelig .venv-src/bin/python -m pip for å unngå at kommandoen utilsiktet kjøres mot et annet miljø. Ikke overta en ukontrollert pakkesamling fra et felles arbeidsmiljø, og ikke gjennomfør generelle oppgraderinger av alle pakkene.

Ifølge dokumentasjonen for venv er prosjektpakker isolert som standard. Miljøet er likevel knyttet til basistolken sin og er ikke en sikkerhetssandkasse. Aktivering er ikke nødvendig når du bruker eksplisitte baner til tolken. Test nå applikasjonen med egnede testdata. Først deretter utføres eksporten.

3. Registrer og kontroller den testede pakkesammensetningen

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

pip freeze viser installerte pakker. Verktøyet er ikke en avhengighetsløser som lager låsefiler, og utelater som standard enkelte oppstartspakker. Filen er derfor et øyeblikksbilde av utgangspunktet, ikke en fullstendig beskrivelse av tolk, verktøy og plattform.

Åpne eksportfilen før hver deling. Kontroller særlig redigerbare installasjoner, lokale baner og private pakke-URL-er. Fjern tilgangsopplysninger fra filer som deles. Avklar samtidig hvordan nødvendige private pakker fortsatt skal kunne nås med autorisert tilgang. Å bare slette slike oppføringer gjør ikke gjenopprettingen fullstendig. Registrer direkte og transitive avhengigheter i stedet for bare å liste opp bibliotekene som brukes direkte.

4. Gjenopprett uavhengig og verifiser

La .venv-src være uendret. Opprett det andre miljøet ved siden av med en egnet, kompatibel tolk, og installer pakkene fra den kontrollerte listen:

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 utelukkende kompatibiliteten mellom de deklarerte avhengighetene. Et resultat uten avvik erstatter verken applikasjonstester eller en sikkerhetsgjennomgang. Utfør derfor de samme funksjonelle kontrollene som i kildemiljøet: for eksempel en planlagt import, en typisk behandlingskjøring og kontroll av resultatene. Start også disse kontrollene uttrykkelig med .venv-rebuild/bin/python. Dokumenter feil og testresultater før du godkjenner gjenopprettingen.

5. Dokumenter plattform og pakkefiler mer detaljert

For bedre etterprøvbarhet bør du i tillegg registrere versjonene av Python og pip som brukes, samt operativsystem og arkitektur. Ifølge pip-veiledningen for gjentakbare installasjoner kan fullstendig fastsatte direkte og transitive avhengigheter samt kontrollerte pakkehasher gjøre prosessen enda sikrere. Hasher bekrefter at pakkefilene er de forventede, ikke at de er fri for skadevare. Wheel-arkiver kan være plattformspesifikke. En pakkesammensetning som er tilgjengelig på en annen arkitektur, er derfor ikke automatisk likeverdig.

6. Sikre en vei tilbake og dokumenter resultatet

Behold det eksisterende miljøet og en sikkerhetskopi av applikasjonen og dataene til det nye oppsettet er verifisert. Ved feil forkaster du bare det nye testmiljøet og undersøker årsaken. Det eksisterende arbeidsgrunnlaget forblir urørt. Virtuelle miljøer opprettes på nytt, de flyttes eller kopieres ikke.

Konklusjon: En brukbar gjenoppretting består av en kontrollert pakkeeksport, en dokumentert plattform og vellykkede applikasjonstester. Denne kombinasjonen gjør endringer etterprøvbare, uten at en pakkeliste forveksles med en omfattende garanti for reproduserbarhet.