uv eller Poetry: Farten avgjør ikke alene

Velg uv for et nytt Python-prosjekt hvis raske installasjoner eller felles avhengighetsstyring i et monorepo er viktig. Behold gjerne Poetry der låsefil, bygging og CI allerede fungerer, med mindre en konkret gevinst forsvarer byttet. I resultattabellen i Python Dependency Management Benchmark fra mai 2025 tok en kald installasjon 0,66 sekunder med uv og 2,20 sekunder med Poetry på macOS med Apple Silicon og Python 3.11.6.

Begge verktøyene bruker pyproject.toml til prosjektopplysninger og avhengighetskrav, og begge kan låse versjoner for senere installasjoner. Valget handler derfor også om hvordan prosjektet er organisert, hva CI-jobbene faktisk bruker tid på, og hvor mye eksisterende oppsett som må endres. For en ny applikasjon er utgangspunktet annerledes enn for et bibliotek som allerede bygges og publiseres gjennom Poetry.

Hva den målte farten betyr

Resultatet gjelder en avgrenset installasjonsoppgave på den oppgitte maskinen. Prosjektet publiserer skript og et kommandoeksempel som fjerner det virtuelle miljøet før hver kjøring. Eksemplet viser derimot ingen tømming av verktøyenes pakkebuffere. «Kald» beskriver dermed tydelig et nytt prosjektmiljø, men gir ikke i seg selv grunnlag for å anta at alle pakker ble lastet ned på nytt.

Det skillet betyr noe i praksis. Tiden for å opprette et miljø påvirkes av hvilke pakker som trengs, om ferdige hjul er tilgjengelige, maskinens arkitektur og om filer allerede ligger i en buffer. Et prosjekt med pakker som må bygges fra kildekode, kan få en annen fordeling av tiden enn prosjektet i målingen. Tallene er et godt argument for å undersøke uv, men ingen prognose for en vilkårlig applikasjon.

Installasjon er dessuten bare ett trinn i CI. Utsjekk av kode, pakking, tester og publisering kan dominere den samlede kjøretiden selv når installasjonen blir raskere. Gevinsten merkes mest når nye miljøer opprettes ofte, for eksempel i mange korte jobber. Dersom testene tar mesteparten av tiden, kan en stor relativ forbedring i installasjonstrinnet gi en liten endring i hele jobben.

Hva låsefilene gjør

uvs prosjektdokumentasjon beskriver pyproject.toml som stedet for prosjektets avhengighetskrav og uv.lock som en plattformuavhengig fil med eksakte oppløste versjoner som bør lagres i versjonskontroll. Prosjektkommandoer kan opprette et virtuelt miljø og synkronisere det mot låsefilen. Det gir teamet et felles utgangspunkt når det samme prosjektet installeres på flere maskiner.

Poetrys dokumentasjon for grunnleggende bruk anbefaler å lagre poetry.lock med en applikasjon, slik at utviklere, CI og produksjonsmiljøer installerer de samme låste avhengighetsversjonene gjennom Poetry. Den skiller samtidig mellom applikasjoner og biblioteker: En applikasjon som installerer et bibliotek, bruker bibliotekets publiserte avhengighetskrav, ikke bibliotekets egen poetry.lock.

Et bibliotek kan fortsatt ha nytte av en låsefil for å gjenskape sitt eget utviklingsmiljø. Den filen forteller imidlertid ikke hvilke kompatible avhengighetsversjoner brukerne faktisk får. Derfor bør bibliotekets tester også dekke versjonene det lover å støtte. Verktøyvalg for biblioteker må i tillegg passe til hvordan pakken bygges og publiseres; en kort installasjonstid avgjør ikke dette alene.

Ved et verktøybytte erstatter ikke en eksisterende poetry.lock arbeidet med å opprette og kontrollere uv.lock. Selv om begge verktøyene leser pyproject.toml, er låsefilene knyttet til hver sin arbeidsflyt. Endringer i oppløste versjoner eller pakkekilder må behandles som reelle prosjektendringer, ikke som en ren omdøping av en fil.

Valget etter prosjekttype

Ny applikasjon: uv passer når miljøer opprettes ofte og teamet vil starte med rask installasjon, prosjektkommandoer og en versjonskontrollert låsefil. Poetry er også et fornuftig valg når teamet allerede kjenner kommandoene og bruker samme oppsett til utvikling og utrulling. I begge tilfeller bør produksjonsløpet installere fra prosjektets låste avhengigheter.
Bibliotek: Se først på bygging, publisering og kompatibilitetstesting. Utviklerne trenger et miljø der feil kan gjenskapes, mens brukernes applikasjoner kan velge andre versjoner innenfor bibliotekets oppgitte grenser. En rask lokal installasjon gir liten verdi hvis testene bare dekker den ene kombinasjonen utviklerne har låst.
Monorepo: uvs dokumentasjon for arbeidsområder beskriver medlemmer med hver sin pyproject.toml og én felles låsefil; kommandoer kan rettes mot et bestemt medlem. Dette er nyttig når beslektede pakker skal løses samlet. Den felles løsningen har også en grense: Medlemmer med motstridende krav eller behov for separate virtuelle miljøer passer dårlig i samme arbeidsområde.
CI: Mål hele jobben og behold låsefilen i versjonskontroll. uvs beskrivelse av låsing og synkronisering viser at --locked gir feil når låsefilen er utdatert, mens uv sync som standard fjerner pakker som ikke hører til det låste miljøet. Dette gir en konkret måte å oppdage avvik mellom prosjektkrav og låsefil på før testene kjøres. Sammenlign likevel total kjøretid, ikke bare installasjonstrinnet.

Når et Poetry-prosjekt bør flyttes

For et eksisterende prosjekt er spørsmålet om uv løser et problem teamet faktisk har. Mange gjentatte installasjoner kan gjøre spart tid verdifull. Flere tett koblede pakker kan gjøre en felles låsefil attraktiv. Hvis dagens CI er stabil og installasjonen utgjør en liten del av jobben, er den publiserte målingen alene et svakt grunnlag for å bytte arbeidsflyt.

En prøveflytting bør bevare den fungerende Poetry-konfigurasjonen mens en ny uv.lock opprettes på en egen gren. Sammenlign de oppløste versjonene og undersøk valgfrie avhengigheter, private pakkekilder og pakker med plattformavhengige distribusjoner. Kontroller også at prosjektet fortsatt kan bygges slik det skal; avhengighetsstyring og byggoppsett er beslektede, men ulike deler av leveransen.

Kjør deretter samme tester og byggesteg med samme Python-versjon og tilsvarende CI-miljø. Ta med både jobber som starter med nytt virtuelt miljø og jobber som kan bruke buffer, siden forholdet mellom installasjon og resten av arbeidet kan endre seg. Et bytte er lettere å begrunne når det forbedrer den samlede arbeidsflyten eller løser et konkret behov for felles prosjektstyring.

Les også: