Waarom we voorlopig bij venv blijven

Om de zoveel tijd wordt een tool snel genoeg dat je je afvraagt of je saaie keuze stilletjes de verkeerde is geworden. Deze maand was dat uv — de op Rust gebouwde installer van Astral — tegenover de stdlib venv + pip + requirements.txt waar elk van onze agent-repos op draait. Ik deed mijn huiswerk grondig: meerdere bronnen, de primaire docs, alles erop en eraan. We blijven bij venv. Het waarom is het deel dat het opschrijven waard is.

Nog steeds de standaard, geen relikwie

Even duidelijk gezegd, want het internet suggereert het tegendeel: venv is geen afgeschreven pad waar je je aan vastklampt. PyPA vermeldt venv en pip nog steeds als de standaardtools om een omgeving aan te maken en erin te installeren. Onze opzet — zes onafhankelijke agent-repos, elk met zijn eigen .venv/, een gedeelde agent-core gepind via commit-SHA en editable geïnstalleerd voor lokale dev — geeft ons al de isolatie en reproduceerbaarheid die we nodig hebben. Hier staat niets in brand.

uv zou echt binnen onze regels passen

Dit is geen “nieuwe tool slecht”-stuk. uv sluit netjes aan op hoe we nu al alles pinnen:

uv pip compile            # exact-version locks, zoals pip-tools
uv add --rev <sha>        # een git-dependency gepind op één commit
uv add --editable ../agent-core   # ons gedeelde framework voor lokale dev
uv sync --locked          # CI-gate die FAALT op een verouderde lock
uv lock --upgrade-package <name>  # één dependency bumpen, gevet, in isolatie

Het is een gedocumenteerde drop-in — uv pip install werkt meestal gewoon — en het zit mee aan tafel voor PEP 751, het nieuwe standaard lock-formaat dat hashes verplicht. Op de inhoud is het een ja.

Dus waarom nog niet

Ons dependencybeleid is de lens voor alles: pin op een exacte versie of SHA, wacht vier weken na een release, lees de upstream-issues, pip-audit proper voor elke bump, jaag nooit op de laatste versie. Die lens geldt ook voor de tools, niet enkel voor wat ze installeren. venv en pip kosten ons nul nieuwe vendor en nul governance-risico — ze zitten in Python zelf. uv is het product van één bedrijf, en tooling van één leverancier kan geherlicentieerd, omgebogen of overgenomen worden — en er gaan al geruchten die kant op.* Dat is net het supply-chain-signaal waarvoor ons beleid bestaat. Je giet het fundament van je build niet opnieuw in hetzelfde seizoen waarin de eigendomsvraag opengaat.

Een tool die je niet goedkoop kunt uitrukken, is geen gemak — het is een dependency. Beoordeel het als één.

Dus hier is het geparkeerde idee, geen engagement: uv later adopteren als een drop-in versneller — uv venv, uv pip install, uv pip compile — terwijl requirements.txt de bron van waarheid blijft en uv nooit een runtime-dependency wordt. Gepind, gevet, vervangbaar op een namiddag. Wanneer het governance-plaatje uitklaart, is dat een schone namiddagwinst. Tot dan houdt saai de sleutels.

---

* Gerucht, niet bevestigd: de overnameberichten waren op het moment van schrijven niet geverifieerd.