Eén Python, veel projecten

Elk programma dat je tot nu toe schreef bestond volledig uit dingen die Python al had. Dat is een echte prestatie, en het is ook ongebruikelijk. De meeste Python-programma’s in de praktijk steunen op code die iemand anders schreef.

Code die je niet zelf schreef

Stel dat je programma een pagina van het internet moet ophalen. Je kunt zelf uitzoeken hoe je het protocol spreekt, wat weken zorgvuldig werk kost. Of je gebruikt code die iemand daar al precies voor heeft geschreven en getest.

Die tweede optie is een pakket: een herbruikbare bundel Python-code die je bewust aan een project toevoegt. Veel pakketten komen van anderen; een team kan ook zijn eigen gedeelde code als pakket aanbieden. Zodra een pakket in een omgeving is geïnstalleerd, kunnen programma’s die die omgeving gebruiken het importeren.

Fundamentals I vertelde je dat pakketten buiten de cursus vielen. Dat was terecht terwijl je de taal zelf leerde. In dit hoofdstuk verandert dat. Aan het einde heb je een pakket geïnstalleerd, vastgelegd welk pakket je project nodig heeft en de hele inrichting opnieuw vanaf nul opgebouwd.

Er zit een addertje onder het gras, en daar gaat de rest van deze les over.

Twee projecten, één plank

Een pakket is niet na één keer schrijven af. Het wordt verbeterd en uitgebreid, en elke uitgave krijgt een versienummer. Je programma heeft niet zomaar “dat pakket” nodig, maar een versie waarvan het gedrag overeenkomt met wat je schreef.

De shell kan je programma nu uitvoeren, maar programma’s die deze Python-omgeving gebruiken bereiken nog steeds dezelfde verzameling geïnstalleerde pakketten. Zie dat als één plank die ze allemaal delen.

Stel je een weerproject voor dat is geschreven voor versie 2 van een pakket. Een maand later begin je een reisproject dat versie 3 nodig heeft. Installeer versie 3 op de gedeelde plank en het weerproject kan ongemerkt stoppen met werken, omdat versie 2 er eenvoudigweg niet meer is. Geen van beide programma’s is verkeerd. Ze rekenden op verschillende dingen op verschillende momenten, en één plank kan niet beide beloftes waarmaken.

Geef het project een eigen grens

Een bruikbaar antwoord is een kleine Python-omgeving in elke projectmap. Het weerproject krijgt zijn pakketversies. Het reisproject krijgt zijn eigen versies. Het ene veranderen richt het andere niet opnieuw in.

Die grens heet een virtuele omgeving. Het is geen virtuele machine en er zit geen ander besturingssysteem in. Het is een map die één project zijn eigen Python-opdracht en eigen plek voor geïnstalleerde pakketten geeft.

We noemen de map .venv. De punt aan het begin is een conventie die zegt: “dit ondersteunt het project; het is geen bronbestand van het project”. Veel editors herkennen die naam automatisch.

Vervangbaar, niet kostbaar

Een virtuele omgeving kan groot zijn, bevat computerspecifieke paden en wordt door hulpmiddelen gemaakt. Het is afgeleide toestand, zoals een gebouwde kopie van iets waarvan je het recept nog hebt. Op de Python Land-site bestaat de omgeving alleen in de werksessie. Die wordt uitgesloten wanneer de kleine projectstructuur wordt opgeslagen of gedownload.

Dat is een voordeel. Je moet .venv kunnen verwijderen of verliezen en opnieuw een gelijkwaardige omgeving kunnen maken. Het blijvende deel is een kort tekstbestand dat zegt wat het project nodig heeft. Dat bestand maak je later in dit hoofdstuk.

Hierna maak je de grens en zie je hoe de shell erbinnen stapt.