4. Använda Python på Windows¶
Detta dokument syftar till att ge en översikt över Windows-specifika beteenden som du bör känna till när du använder Python på Microsoft Windows.
Till skillnad från de flesta Unix-system och -tjänster innehåller Windows inte en systemstödd installation av Python. Istället kan Python erhållas från ett antal distributörer, inklusive direkt från CPython-teamet. Varje Python-distribution har sina egna fördelar och nackdelar, men konsekvens med andra verktyg som du använder är i allmänhet en värdefull fördel. Innan du går vidare med den process som beskrivs här rekommenderar vi att du undersöker dina befintliga verktyg för att se om de kan tillhandahålla Python direkt.
Om du vill hämta Python från CPython-teamet använder du Python Install Manager. Det här är ett fristående verktyg som gör Python tillgängligt som globala kommandon på din Windows-maskin, integreras med systemet och stöder uppdateringar över tid. Du kan ladda ner Python Install Manager från python.org/downloads eller via Microsoft Store-appen.
När du har installerat Python Install Manager kan det globala kommandot python
användas från vilken terminal som helst för att starta den senaste versionen av Python. Denna version kan ändras över tiden när du lägger till eller tar bort olika versioner, och kommandot py list
visar vilken som är aktuell.
I allmänhet rekommenderar vi att du skapar en virtuell miljö för varje projekt och kör <env>\Scripts\Activate
i din terminal för att använda den. Detta ger isolering mellan projekt, konsekvens över tid och säkerställer att ytterligare kommandon som läggs till av paket också är tillgängliga i din session. Skapa en virtuell miljö med hjälp av python -m venv <env path>
.
Om kommandona python
eller py
inte verkar fungera, se avsnittet Felsökning nedan. Ibland krävs ytterligare manuella steg för att konfigurera din dator.
Förutom att använda Pythons installationshanterare kan Python också erhållas som NuGet-paket. Se Paket från nuget.org nedan för mer information om dessa paket.
De inbäddningsbara distros är minimala paket av Python som är lämpliga för inbäddning i större applikationer. De kan installeras med hjälp av Pythons installationshanterare. Se Det inbäddningsbara paketet nedan för mer information om dessa paket.
4.1. Pythons installationshanterare¶
4.1.1. Installation¶
Pythons installationshanterare kan installeras från Microsoft Store app eller laddas ner och installeras från python.org/downloads. De två versionerna är identiska.
För att installera via Store klickar du bara på ”Install”. När det har slutförts öppnar du en terminal och skriver python
för att komma igång.
För att installera filen som laddats ner från python.org, antingen dubbelklicka och välj ”Install”, eller kör Add-AppxPackage <path to MSIX>
i Windows Powershell.
Efter installationen bör kommandona python
, py
och pymanager
vara tillgängliga. Om du har befintliga installationer av Python, eller om du har ändrat din PATH
-variabel, kan du behöva ta bort dem eller ångra ändringarna. Se Felsökning för mer hjälp med att åtgärda kommandon som inte fungerar.
När du först installerar en körning kommer du troligen att bli ombedd att lägga till en katalog i din PATH
. Detta är valfritt om du föredrar att använda kommandot py
, men erbjuds för dem som föredrar att hela utbudet av alias (som python3.14.exe
) ska vara tillgängligt. Katalogen kommer att vara %LocalAppData%\Python\bin
som standard, men kan anpassas av en administratör. Klicka på Start och sök efter ”Redigera miljövariabler för ditt konto” på sidan för systeminställningar för att lägga till sökvägen.
Varje Python-körtid som du installerar har sin egen katalog för skript. Dessa måste också läggas till i PATH
om du vill använda dem.
Installationshanteraren för Python kommer automatiskt att uppdateras till nya utgåvor. Detta påverkar inte några installationer av Python runtimes. Avinstallation av Python installationshanterare avinstallerar inte några Python runtimes.
Om du inte kan installera en MSIX i ditt sammanhang, till exempel om du använder automatiserad distributionsprogramvara som inte stöder det eller om du riktar in dig på Windows Server 2019, se Avancerad installation nedan för mer information.
4.1.2. Grundläggande användning¶
Det rekommenderade kommandot för att starta Python är python
, som antingen startar den version som begärs av skriptet som startas, en aktiv virtuell miljö eller den standardinstallerade versionen, som kommer att vara den senaste stabila versionen om inget annat har konfigurerats. Om ingen version specifikt begärs och inga runtimes installeras alls, kommer den senaste versionen att installeras automatiskt.
För alla scenarier som involverar flera runtime-versioner är det rekommenderade kommandot py
. Det kan användas var som helst i stället för python
eller den äldre startprogrammet py.exe
. Som standard matchar py
beteendet hos python
, men tillåter också kommandoradsalternativ för att välja en specifik version samt underkommandon för att hantera installationer. Dessa beskrivs närmare nedan.
Eftersom kommandot py
redan kan vara upptaget av den tidigare versionen finns det också ett entydigt kommando pymanager
. Skriptbaserade installationer som avser att använda Python Install Manager bör överväga att använda pymanager
, eftersom risken för konflikter med befintliga installationer är mindre. Den enda skillnaden mellan de två kommandona är när de körs utan argument: py
installerar och startar din standardtolkar, medan pymanager
visar hjälp (pymanager exec ...
fungerar på samma sätt som py ...
).
Var och en av dessa kommandon har också en fönsterversion som undviker att skapa ett konsolfönster. Dessa är pyw
, pythonw
och pymanagerw
. Ett python3
-kommando ingår också som efterliknar kommandot python
. Det är avsett att fånga upp oavsiktlig användning av det typiska POSIX-kommandot i Windows, men är inte avsett att användas i stor utsträckning eller rekommenderas.
Om du vill starta din standardkörning kör du python
eller py
med de argument som du vill ska skickas till körningen (t.ex. skriptfiler eller den modul som ska startas):
$> py
...
$> python my-script.py
...
$> py -m this
...
Standardkörtiden kan åsidosättas med miljövariabeln PYTHON_MANAGER_DEFAULT
eller en konfigurationsfil. Se Konfiguration för information om konfigurationsinställningar.
För att starta en specifik körning accepterar kommandot py
ett -V:<TAG>
alternativ. Detta alternativ måste specificeras före alla andra. Taggen är en del av eller hela identifieraren för körningen; för dem från CPython-teamet ser det ut som versionen, eventuellt med plattformen. För kompatibilitet kan V:
utelämnas i fall där taggen hänvisar till en officiell version och börjar med 3
.
$> py -V:3.14 ...
$> py -V:3-arm64 ...
Runtimes från andra distributörer kan kräva att företaget också inkluderas. Detta ska separeras från taggen med ett snedstreck och kan vara ett prefix. Att ange företaget är valfritt när det är PythonCore
, och att ange taggen är valfritt (men inte snedstrecket) när du vill ha den senaste utgåvan från ett specifikt företag.
$> py -V:Distributor\1.0 ...
$> py -V:distrib/ ...
Om ingen version anges, men en skriptfil skickas, kommer skriptet att inspekteras för en shebang-rad. Detta är ett speciellt format för den första raden i en fil som gör det möjligt att åsidosätta kommandot. Se Shebang-rader för mer information. Om det inte finns någon shebang-rad, eller om den inte kan lösas, kommer skriptet att startas med standardkörtiden.
Om du kör i en aktiv virtuell miljö, inte har begärt en viss version och det inte finns någon shebang-rad, kommer standardkörningen att vara den virtuella miljön. I det här scenariot var kommandot python
troligen redan åsidosatt och ingen av dessa kontroller gjordes. Detta beteende säkerställer dock att kommandot py
kan användas på ett utbytbart sätt.
När du startar antingen python
eller py
men inte har några runtimes installerade, och den begärda versionen är standardversionen, kommer den att installeras automatiskt och sedan startas. Annars kommer den begärda versionen att installeras om automatisk installation är konfigurerad (troligen genom att ställa in PYTHON_MANAGER_AUTOMATIC_INSTALL
till true
), eller om py exec
eller pymanager exec
formerna av kommandot användes.
4.1.3. Kommandohjälp¶
Kommandot py help
visar den fullständiga listan över kommandon som stöds, tillsammans med deras alternativ. Alla kommandon kan få alternativet -?
för att visa dess hjälp, eller dess namn som skickas till py help
.
$> py help
$> py help install
$> py install /?
Alla kommandon stöder vissa gemensamma alternativ, som visas av py help
. Dessa alternativ måste anges efter varje underkommando. Om du anger -v
eller --verbose
ökar mängden utdata som visas, och -vv
ökar den ytterligare för felsökningsändamål. Om du anger -q
eller --quiet
minskar utdata, och -qq
minskar den ytterligare.
Alternativet --config=<PATH>
gör det möjligt att ange en konfigurationsfil för att åsidosätta flera inställningar på en gång. Se Konfiguration nedan för mer information om dessa filer.
4.1.4. Lista körtider¶
$> py list [-f=|--format=<FMT>] [-1|--one] [--online|-s=|--source=<URL>] [<TAG>...]
Listan över installerade körtider kan ses med hjälp av py list
. Ett filter kan läggas till i form av en eller flera taggar (med eller utan företagsspecifikator), och var och en kan innehålla ett prefix <
, <=
, >=
eller >
för att begränsa till ett intervall.
En rad olika format stöds och kan anges med alternativen --format=<FMT>
eller -f <FMT>
. Formaten inkluderar table
(en användarvänlig tabellvy), csv
(kommaseparerad tabell), json
(en enda JSON-blob), jsonl
(en JSON-blob per resultat), exe
(bara sökvägen till den körbara filen), prefix
(bara sökvägen till prefixet).
Alternativet --one
eller -1
visar bara ett enda resultat. Om standardkörtiden är inkluderad kommer den att vara den enda. Annars visas det ”bästa” resultatet (”bästa” är avsiktligt vagt definierat, men kommer vanligtvis att vara den senaste versionen). Resultatet som visas av py list --one <TAG>
kommer att matcha den körtid som skulle startas av py -V:<TAG>
.
Alternativet --only-managed
utesluter resultat som inte installerats av Pythons installationshanterare. Detta är användbart när man ska avgöra vilka runtimes som kan uppdateras eller avinstalleras med kommandot py
.
Alternativet --online
är en förkortning för att skicka --source=<URL>
med standardkällan. Om något av dessa alternativ anges kommer online-indexet att söka efter körtider som kan installeras. Resultatet som visas av py list --online --one <TAG>
kommer att matcha den körtid som skulle installeras av py install <TAG>
.
$> py list --online 3.14
För kompatibilitet med den gamla startprogrammet behålls kommandona --list
, --list-paths
, -0
och -0p
(t.ex. py -0p
). De tillåter inga ytterligare alternativ och kommer att producera utdata i äldre format.
4.1.5. Installera körtider¶
$> py install [-s=|--source=<URL>] [-f|--force] [-u|--update] [--dry-run] [<TAG>...]
Nya körtidsversioner kan läggas till med hjälp av py install
. En eller flera taggar kan anges och den speciella taggen default
kan användas för att välja standard. Intervall stöds inte för installation.
Alternativet --source=<URL>
gör det möjligt att åsidosätta det onlineindex som används för att få fram körtider. Detta kan användas med ett offline-index, som visas i Offline-installationer.
Om du anger --force
ignoreras alla cachade filer och alla befintliga installationer tas bort för att ersättas med den angivna.
Om du skickar --update
kommer befintliga installationer att ersättas om den nya versionen är nyare. Annars kommer de att lämnas kvar. Om inga taggar anges med --update
kommer alla installationer som hanteras av Pythons installationshanterare att uppdateras om nyare versioner finns tillgängliga. Uppdateringar kommer att ta bort alla ändringar som gjorts i installationen, inklusive globalt installerade paket, men virtuella miljöer kommer att fortsätta att fungera.
Om du anger --dry-run
kommer utdata och loggar att genereras, men inga installationer kommer att ändras.
Förutom ovanstående alternativ kommer alternativet --target
att extrahera runtimen till den angivna katalogen istället för att göra en normal installation. Detta är användbart för att bädda in runtimes i större applikationer.
$> py install ... [-t=|--target=<PATH>] <TAG>
4.1.6. Offline-installationer¶
För att utföra offlineinstallationer av Python måste du först skapa ett offlineindex på en maskin som har nätverksåtkomst.
$> py install --download=<PATH> ... <TAG>...
Alternativet --download=<PATH>
hämtar paketen för de listade taggarna och skapar en katalog som innehåller dem och en index.json
-fil som är lämplig för senare installation. Hela denna katalog kan flyttas till offlinemaskinen och användas för att installera en eller flera av de medföljande körtiderna:
$> py install --source="<PATH>\index.json" <TAG>...
Installationshanteraren Python kan installeras genom att ladda ner installationsprogrammet och flytta det till en annan maskin innan det installeras.
Alternativt kan ZIP-filerna i en offline-indexkatalog helt enkelt överföras till en annan maskin och extraheras. Detta kommer inte att registrera installationen på något sätt, och den måste därför startas genom att direkt referera till de körbara filerna i den extraherade katalogen, men det är ibland ett bättre tillvägagångssätt i fall där det inte är möjligt eller bekvämt att installera Pythons installationshanterare.
På så sätt kan Python runtimes installeras och hanteras på en maskin som inte har tillgång till internet.
4.1.7. Avinstallation av Runtimes¶
$> py uninstall [-y|--yes] <TAG>...
Runtimes kan tas bort med kommandot py uninstall
. En eller flera taggar måste anges. Intervall stöds inte här.
Alternativet --yes
förbigår bekräftelseprompten före avinstallationen.
Istället för att skicka taggar individuellt kan alternativet --purge
anges. Detta kommer att ta bort alla runtimes som hanteras av Pythons installationshanterare, inklusive rensning av Start-menyn, registret och eventuella nedladdningscacher. Körtider som inte installerades av Pythons installationshanterare påverkas inte, och inte heller manuellt skapade konfigurationsfiler.
$> py uninstall [-y|--yes] --purge
Installationshanteraren för Python kan avinstalleras via inställningssidan ”Installerade appar” i Windows. Detta tar inte bort några runtimes, och de kommer fortfarande att vara användbara, även om de globala kommandona python
och py
kommer att tas bort. Om du installerar om Python-installationshanteraren kan du hantera dessa runtimes igen. För att helt rensa upp alla Python-körtider kör du med --purge
innan du avinstallerar Python-installationshanteraren.
4.1.8. Konfiguration¶
Python installationshanterare konfigureras med en hierarki av konfigurationsfiler, miljövariabler, kommandoradsalternativ och registerinställningar. I allmänhet har konfigurationsfiler möjlighet att konfigurera allt, inklusive platsen för andra konfigurationsfiler, medan registerinställningar endast är administratörsbehöriga och åsidosätter konfigurationsfiler. Kommandoradsalternativen åsidosätter alla andra inställningar, men alla alternativ är inte tillgängliga.
I det här avsnittet beskrivs standardinställningarna, men tänk på att modifierade eller åsidosatta installationer kan lösa inställningarna på ett annat sätt.
En global konfigurationsfil kan konfigureras av en administratör och läses då först. Användarkonfigurationsfilen lagras i %AppData%\Python\pymanager.json
(som standard) och läses nästa gång, varvid eventuella inställningar från tidigare filer skrivs över. En ytterligare konfigurationsfil kan anges som miljövariabeln PYTHON_MANAGER_CONFIG
eller kommandoradsalternativet --config
(men inte båda).
Följande inställningar är sådana som sannolikt kommer att ändras vid normal användning. I senare avsnitt listas de inställningar som är avsedda för administrativ anpassning.
Standardkonfigurationsalternativ
Konfigureringsnyckel |
Miljövariabel |
Beskrivning |
---|---|---|
|
|
Den föredragna standardversionen för att starta eller installera. Som standard tolkas detta som den senaste versionen utan förhandsversion från CPython-teamet. |
|
|
Den föredragna standardplattformen för att starta eller installera. Detta behandlas som ett suffix till den angivna taggen, så att |
|
|
Den plats där loggfiler skrivs. Som standard är |
|
|
True för att tillåta automatiska installationer när du anger en viss runtime som ska startas. Som standard är true. |
|
|
True för att tillåta listning och start av runtimes som inte installerats av Pythons installationshanterare, eller false för att utesluta dem. Som standard är true. |
|
|
True för att tillåta shebangs i |
|
|
Ställ in standardnivån för utmatning (0-50). Som standard är 20. Lägre värden ger mer utdata. Miljövariablerna är booleska och kan producera ytterligare utdata under uppstarten som senare undertrycks av annan konfiguration. |
|
|
True för att bekräfta vissa åtgärder innan de utförs (t.ex. avinstallation), eller false för att hoppa över bekräftelsen. Som standard är true. |
|
|
Åsidosätt indexflödet för att hämta nya installationer från. |
|
|
Ange det standardformat som används av kommandot |
Punktade namn ska vara kapslade inuti JSON-objekt, till exempel skulle list.format
anges som {"list": {"format": "table"}}
.
4.1.9. Shebang-rader¶
Om den första raden i en skriptfil börjar med #!
kallas den för en ”shebang”-rad. Linux och andra Unix-liknande operativsystem har inbyggt stöd för sådana rader och de används ofta i sådana system för att ange hur ett skript ska exekveras. Kommandona python
och py
gör det möjligt att använda samma funktioner med Python-skript i Windows.
För att shebang-rader i Python-skript ska kunna portas mellan Unix och Windows stöds ett antal ”virtuella” kommandon för att ange vilken tolk som ska användas. De virtuella kommandon som stöds är:
/usr/bin/env <ALIAS>
/usr/bin/env -S <ALIAS>
/usr/bin/<ALIAS>
/usr/local/bin/<ALIAS>
<ALIAS>
Om till exempel den första raden i ditt skript börjar med
#! /usr/bin/python
Standard-Python eller en aktiv virtuell miljö kommer att hittas och användas. Eftersom många Python-skript som skrivits för att fungera på Unix redan har den här raden, bör du upptäcka att dessa skript kan användas av startprogrammet utan modifiering. Om du skriver ett nytt skript på Windows som du hoppas ska vara användbart på Unix, bör du använda en av shebang-raderna som börjar med /usr
.
Alla ovanstående virtuella kommandon kan ersättas av <ALIAS>
med ett alias från en installerad körtid. Det innebär att alla kommandon som genereras i den globala aliaskatalogen (som du kan ha lagt till i din miljövariabel PATH
) kan användas i en shebang, även om de inte finns i din PATH
. Detta gör det möjligt att använda shebangs som /usr/bin/python3.12
för att välja en viss körtid.
Om inga runtimes är installerade, eller om automatisk installation är aktiverad, kommer den begärda runtimen att installeras vid behov. Se Konfiguration för information om konfigurationsinställningar.
Formen /usr/bin/env
av shebang-raden kommer också att söka i miljövariabeln PATH
efter okända kommandon. Detta motsvarar beteendet hos Unix-programmet env
, som utför samma sökning, men föredrar att starta kända Python-kommandon. En varning kan visas vid sökning efter godtyckliga körbara filer, och denna sökning kan inaktiveras med konfigurationsalternativet hebang_can_run_anything
.
Shebang-rader som inte matchar något av mönstren behandlas som Windows körbara sökvägar som är absoluta eller relativa till den katalog som innehåller skriptfilen. Detta är en bekvämlighet för skript som endast används i Windows, t.ex. skript som genereras av ett installationsprogram, eftersom beteendet inte är kompatibelt med skal i Unix-stil. Dessa sökvägar kan vara citerade och kan innehålla flera argument, varefter sökvägen till skriptet och eventuella ytterligare argument läggs till. Denna funktion kan inaktiveras med konfigurationsalternativet hebang_can_run_anything
.
Anteckning
Beteendet hos shebangs i Python-installationshanteraren skiljer sig något från det tidigare startprogrammet py.exe
, och de gamla konfigurationsalternativen gäller inte längre. Om du är beroende av det gamla beteendet eller den gamla konfigurationen rekommenderar vi att du behåller det gamla startprogrammet. Den kan laddas ned separat och installeras på egen hand. Den äldre startprogrammets kommando py
kommer att åsidosätta PyManagers kommando, och du måste använda pymanager
-kommandon för installation och avinstallation.
4.1.10. Avancerad installation¶
För situationer där en MSIX inte kan installeras, till exempel vissa äldre administrativa distributionsplattformar, finns det en MSI tillgänglig från nedladdningssidan för python.org. Denna MSI har inget användargränssnitt och kan bara utföra installationer per maskin till sin standardplats i Program Files. Den kommer att försöka ändra systemets PATH
-miljövariabel så att den inkluderar denna installationsplats, men se till att validera detta i din konfiguration.
Anteckning
Windows Server 2019 är den enda versionen av Windows som CPython stöder som inte stöder MSIX. För Windows Server 2019 bör du använda MSI.
Tänk på att MSI-paketet inte innehåller några runtimes och därför inte är lämpligt för installationer i offline-miljöer utan att även skapa ett offline-installationsindex. Se Offline-installationer och Administrativ konfiguration för information om hur du hanterar dessa scenarier.
Körtider som installeras av MSI delas med dem som installeras av MSIX, och är alla endast per användare. Pythons installationshanterare stöder inte installation av runtimes per maskin. För att emulera en installation per maskin kan du använda py install --target=<shared location>
som administratör och lägga till dina egna systemomfattande ändringar i PATH
, registret eller Start-menyn.
När MSIX är installerat, men kommandon inte finns tillgängliga i miljövariabeln PATH
, kan de hittas under %LocalAppData%\Microsoft\WindowsApps\PythonSoftwareFoundation.PythonManager_3847v3x7pw1km
eller %LocalAppData%\Microsoft\WindowsApps\PythonSoftwareFoundation.PythonManager_qbz5n2kfra8p0
, beroende på om det installerades från python.org eller via Windows Store. Det rekommenderas inte att försöka köra den körbara filen direkt från Program Files.
För att programmatiskt installera Python-installationshanteraren är det enklast att använda WinGet, som ingår i alla versioner av Windows som stöds:
$> winget install 9NQ7512CXL7T -e --accept-package-agreements --disable-interactivity
# Valfritt, kör konfigurationskontrollen och acceptera alla ändringar
$> py install --configure -y
För att ladda ner Python-installationshanteraren och installera på en annan maskin kommer följande WinGet-kommando att ladda ner de nödvändiga filerna från Store till din nedladdningskatalog (lägg till -d <location>
för att anpassa utmatningsplatsen). Detta genererar också en YAML-fil som verkar vara onödig, eftersom den nedladdade MSIX kan installeras genom att starta eller använda kommandona nedan.
$> winget download 9NQ7512CXL7T -e --skip-license --accept-package-agreements --accept-source-agreements
För att programmatiskt installera eller avinstallera en MSIX med hjälp av PowerShell rekommenderas PowerShell-cmdlets Add-AppxPackage och Remove-AppxPackage:
$> Add-AppxPackage C:\Downloads\python-manager-25.0.msix
...
$> Get-AppxPackage PythonSoftwareFoundation.PythonManager | Remove-AppxPackage
Den senaste versionen kan laddas ner och installeras av Windows genom att skicka AppInstaller-filen till kommandot Add-AppxPackage. Detta installeras med hjälp av MSIX på python.org och rekommenderas endast för fall där installation via Store (interaktivt eller med WinGet) inte är möjlig.
$> Add-AppxPackage -AppInstallerFile https://www.python.org/ftp/python/pymanager/pymanager.appinstaller
Andra verktyg och API:er kan också användas för att tillhandahålla ett MSIX-paket för alla användare på en maskin, men Python anser inte att detta är ett scenario som stöds. Vi föreslår att du tittar på PowerShell Add-AppxProvisionedPackage cmdlet, den inbyggda Windows PackageManager-klassen eller dokumentationen och stödet för ditt distributionsverktyg.
Oavsett installationsmetod måste användarna fortfarande installera sina egna kopior av Python, eftersom det inte finns något sätt att utlösa dessa installationer utan att vara en inloggad användare. När MSIX används kommer den senaste versionen av Python att vara tillgänglig för alla användare att installera utan nätverksåtkomst.
Observera att MSIX som kan laddas ner från butiken och från Pythons webbplats är subtilt olika och inte kan installeras samtidigt. När det är möjligt föreslår vi att du använder ovanstående WinGet-kommandon för att ladda ner paketet från Store för att minska risken för att skapa motstridiga installationer. Det finns inga licensbegränsningar för Pythons installationshanterare som skulle förhindra att Store-paketet används på det här sättet.
4.1.11. Administrativ konfiguration¶
Det finns ett antal alternativ som kan vara användbara för administratörer för att åsidosätta konfigurationen av Python-installationshanteraren. Dessa kan användas för att tillhandahålla lokal cachelagring, inaktivera vissa genvägstyper, åsidosätta medföljande innehåll. Alla ovanstående konfigurationsalternativ kan ställas in, liksom de nedan.
Konfigurationsalternativ kan åsidosättas i registret genom att ange värden under HKEY_LOCAL_MACHINE\Software\Policies\Python\PyManager
, där värdenamnet matchar konfigurationsnyckeln och värdetypen är REG_SZ
. Observera att den här nyckeln i sig kan anpassas, men endast genom att ändra konfigurationsfilen för kärnan som distribueras med Python-installationshanteraren. Vi rekommenderar dock att registervärden endast används för att ställa in base_config
till en JSON-fil som innehåller den fullständiga uppsättningen åsidosättningar. Åsidosättningar av registernycklar kommer att ersätta alla andra konfigurerade inställningar, medan base_config
tillåter användare att ytterligare modifiera inställningar som de kan behöva.
Observera att de flesta inställningar med miljövariabler stöder dessa variabler eftersom deras standardinställning anger variabeln. Om du åsidosätter dem kommer miljövariabeln inte längre att fungera, såvida du inte åsidosätter den med en annan. Exempelvis är standardvärdet för confirm
bokstavligen %PYTHON_MANAGER_CONFIRM%
, vilket innebär att variabeln löses vid laddning. Om du åsidosätter värdet till yes
kommer miljövariabeln inte längre att användas. Om du åsidosätter värdet till %CONFIRM%
kommer den miljövariabeln att användas i stället.
Konfigurationsinställningar som är sökvägar tolkas som relativa till den katalog som innehåller den konfigurationsfil som angav dem.
Administrativa konfigurationsalternativ
Konfigureringsnyckel |
Beskrivning |
---|---|
|
Den konfigurationsfil med högst prioritet som ska läsas. Observera att det bara är den inbyggda konfigurationsfilen och registret som kan ändra den här inställningen. |
|
Den andra konfigurationsfilen som ska läsas. |
|
Den tredje konfigurationsfilen som ska läsas. |
|
Registerplats för att kontrollera om det finns åsidosättningar. Observera att endast den inbyggda konfigurationsfilen kan ändra den här inställningen. |
|
Skrivskyddad katalog som innehåller lokalt cachade filer. |
|
Sökväg eller URL till ett index som ska användas när huvudindexet inte kan nås. |
|
Kommaseparerad lista över genvägstyper som ska tillåtas (t.ex. |
|
Kommaseparerad lista över genvägstyper som ska uteslutas (t.ex. |
|
Registerplats att läsa och skriva PEP 514-poster till. Som standard är |
|
Startmenymapp att skriva genvägar till. Som standard är det |
|
Sökväg till den aktiva virtuella miljön. Som standard är detta |
|
True för att undertrycka synliga varningar när en shebang startar ett annat program än en Python-körtid. |
4.1.12. Installera fritt trådade binärfiler¶
Tillagd i version 3.13: (Experimentell)
Anteckning
Allt som beskrivs i det här avsnittet betraktas som experimentellt och kan förväntas ändras i framtida versioner.
Förbyggda distributioner av den experimentella fri-threaded-byggnaden finns tillgängliga genom att installera taggar med suffixet t
.
$> py install 3.14t
$> py install 3.14t-arm64
$> py install 3.14t-32
Detta kommer att installeras och registreras som normalt. Om du inte har några andra körtider installerade kommer python
att starta den här. Annars måste du använda py -V:3.14t ...
eller, om du har lagt till den globala aliaskatalogen i din PATH
-miljövariabel, kommandona python3.14t.exe
.
4.1.13. Felsökning¶
Om din Python-installationshanterare inte verkar fungera korrekt, arbeta igenom dessa tester och korrigeringar för att se om det hjälper. Om inte, rapportera ett problem på vår buggtracker, inklusive alla relevanta loggfiler (skrivs till din %TEMP%
-katalog som standard).
Felsökning
Symtom |
Saker att prova |
---|---|
|
|
Klicka på Start, öppna ”Manage app execution aliases” och kontrollera att aliasen för ”Python (default)” är aktiverade. Om de redan är det kan du försöka inaktivera och återaktivera för att uppdatera kommandot. Kommandona ”Python (standardfönster)” och ”Python installationshanterare” kan också behöva uppdateras. |
|
Kontrollera att kommandona |
|
|
|
Klicka på Start, öppna ”Manage app execution aliases” och kontrollera att aliasen för ”Python (default)” är aktiverade. Om de redan är det kan du försöka inaktivera och återaktivera för att uppdatera kommandot. Kommandona ”Python (standardfönster)” och ”Python installationshanterare” kan också behöva uppdateras. |
|
|
Detta betyder vanligtvis att du har den äldre startprogrammet installerat och att det har prioritet över Python-installationshanteraren. För att ta bort det, klicka på Start, öppna ”Installerade appar”, sök efter ”Python launcher” och avinstallera det. |
|
Klicka på Start, öppna ”Installerade appar”, leta efter eventuella befintliga Python-runtimes och ta antingen bort dem eller ändra och inaktivera |
Klicka på Start, öppna ”Manage app execution aliases” och kontrollera att ditt alias |
|
|
Kontrollera din |
Installationer som hanteras av Pythons installationshanterare kommer att väljas före ohanterade installationer. Använd |
|
Prerelease- och experimentinstallationer som inte hanteras av Pythons installationshanterare kan väljas före stabila utgåvor. Konfigurera din standardtagg eller avinstallera prerelease-körtiden och installera om med |
|
|
Klicka på Start, öppna ”Manage app execution aliases” och kontrollera att dina alias |
|
Har du aktiverat en virtuell miljö? Kör skriptet |
Paketet kan vara tillgängligt men sakna den genererade körbara filen. Vi rekommenderar att du använder kommandot |
4.2. Det inbäddningsbara paketet¶
Tillagd i version 3.5.
Den inbäddade distributionen är en ZIP-fil som innehåller en minimal Python-miljö. Den är avsedd att fungera som en del av en annan applikation, snarare än att vara direkt tillgänglig för slutanvändare.
Om du vill installera en inbäddad distribution rekommenderar vi att du använder py install
med alternativet --target
:
$> py install 3.14-embed --target=runtime
När den inbäddade distributionen extraheras är den (nästan) helt isolerad från användarens system, inklusive miljövariabler, systemregisterinställningar och installerade paket. Standardbiblioteket ingår som förkompilerade och optimerade .pyc
-filer i en ZIP, och python3.dll
, python313.dll
, python.exe
och pythonw.exe
tillhandahålls alla. Tcl/tk (inklusive alla underordnade program, t.ex. Idle), pip och Python-dokumentationen ingår inte.
En standardfil ._pth
ingår, som ytterligare begränsar standardsökvägarna (enligt beskrivningen nedan i Hitta moduler). Denna fil är avsedd för inbäddare att modifiera efter behov.
Tredjepartspaket bör installeras av programinstallationsprogrammet vid sidan av den inbäddade distributionen. Att använda pip för att hantera beroenden som i en vanlig Python-installation stöds inte av den här distributionen, men med lite försiktighet kan det vara möjligt att inkludera och använda pip för automatiska uppdateringar. I allmänhet bör tredjepartspaket behandlas som en del av programmet (”vendoring”) så att utvecklaren kan säkerställa kompatibilitet med nyare versioner innan uppdateringar tillhandahålls till användarna.
De två rekommenderade användningsområdena för denna distribution beskrivs nedan.
4.2.1. Python-tillämpning¶
En applikation som är skriven i Python kräver inte nödvändigtvis att användarna är medvetna om detta faktum. Den inbäddade distributionen kan användas i det här fallet för att inkludera en privat version av Python i ett installationspaket. Beroende på hur transparent det ska vara (eller omvänt, hur professionellt det ska se ut) finns det två alternativ.
Att använda en specialiserad körbar fil som startprogram kräver en del kodning, men ger den mest transparenta upplevelsen för användarna. Med ett anpassat startprogram finns det inga uppenbara indikationer på att programmet körs på Python: ikoner kan anpassas, företags- och versionsinformation kan anges och filassociationer fungerar korrekt. I de flesta fall bör ett anpassat startprogram helt enkelt kunna anropa Py_Main
med en hårdkodad kommandorad.
Det enklaste sättet är att tillhandahålla en batchfil eller en genererad genväg som direkt anropar python.exe
eller pythonw.exe
med de kommandoradsargument som krävs. I det här fallet ser programmet ut att vara Python och inte dess faktiska namn, och användare kan ha problem med att skilja det från andra Python-processer eller filassociationer som körs.
Med det senare tillvägagångssättet bör paketen installeras som kataloger tillsammans med den körbara Python-filen för att säkerställa att de finns tillgängliga på sökvägen. Med den specialiserade startprogrammet kan paketen placeras på andra platser eftersom det finns en möjlighet att ange sökvägen innan programmet startas.
4.2.2. Inbäddning av Python¶
Applikationer som är skrivna i inbyggd kod kräver ofta någon form av skriptspråk, och den inbäddade Python-distributionen kan användas för detta ändamål. I allmänhet är större delen av programmet i ursprunglig kod, och en del kommer antingen att anropa python.exe
eller direkt använda python3.dll
. I båda fallen räcker det med att extrahera den inbäddade distributionen till en underkatalog i programinstallationen för att tillhandahålla en laddningsbar Python-tolk.
Precis som vid programanvändning kan paket installeras på valfri plats eftersom det finns möjlighet att ange sökvägar innan tolken initieras. I övrigt finns det inga grundläggande skillnader mellan att använda den inbäddade distributionen och en vanlig installation.
4.3. Paket från nuget.org¶
Tillagd i version 3.5.2.
Paketet nuget.org är en förminskad Python-miljö avsedd att användas i system för kontinuerlig integration och byggande som inte har en systemomfattande installation av Python. Även om nuget är ”pakethanteraren för .NET” fungerar den också perfekt för paket som innehåller verktyg för byggtid.
Besök nuget.org för den mest uppdaterade informationen om hur du använder nuget. Det som följer är en sammanfattning som är tillräcklig för Python-utvecklare.
Kommandoradsverktyget nuget.exe
kan laddas ner direkt från https://aka.ms/nugetclidl
, till exempel med hjälp av curl eller PowerShell. Med verktyget installeras den senaste versionen av Python för 64-bitars eller 32-bitars maskiner med hjälp av:
nuget.exe install python -ExcludeVersion -OutputDirectory .
nuget.exe install pythonx86 -ExcludeVersion -OutputDirectory .
Om du vill välja en viss version lägger du till -Version 3.x.y
. Utdatakatalogen kan ändras från .
och paketet kommer att installeras i en underkatalog. Som standard har underkatalogen samma namn som paketet, och utan alternativet -ExcludeVersion
kommer namnet att inkludera den specifika version som installerats. I underkatalogen finns en katalog med namnet tools
som innehåller Python-installationen:
# Utan -ExcludeVersion
> .\python.3.5.2\tools\python.exe -V
Python 3.5.2
# Med -ExcludeVersion
> .\python\tools\python.exe -V
Python 3.5.2
I allmänhet är nuget-paket inte uppgraderingsbara och nyare versioner bör installeras sida vid sida och refereras till med hjälp av den fullständiga sökvägen. Alternativt kan du ta bort paketkatalogen manuellt och installera den igen. Många CI-system gör detta automatiskt om de inte bevarar filer mellan builds.
Vid sidan av katalogen tools
finns en katalog build\native
. Den innehåller en MSBuild-egenskapsfil python.props
som kan användas i ett C++-projekt för att referera till Python-installationen. Om du inkluderar inställningarna kommer du automatiskt att använda rubrikerna och importbiblioteken i ditt bygge.
Paketinformationssidorna på nuget.org är www.nuget.org/packages/python för 64-bitarsversionen, www.nuget.org/packages/pythonx86 för 32-bitarsversionen och www.nuget.org/packages/pythonarm64 för ARM64-versionen
4.3.1. Fritt trådade paket¶
Tillagd i version 3.13: (Experimentell)
Anteckning
Allt som beskrivs i det här avsnittet betraktas som experimentellt och kan förväntas ändras i framtida versioner.
Paket som innehåller fritt trådade binärfiler har namnen python-freethreaded för 64-bitarsversionen, pythonx86-freethreaded för 32-bitarsversionen och pythonarm64-freethreaded för ARM64-versionen. Dessa paket innehåller både ingångspunkterna python3.13t.exe
och python.exe
, som båda körs med fri tråd.
4.4. Alternativa paketeringar¶
Förutom standarddistributionen av CPython finns det modifierade paket som innehåller ytterligare funktioner. Nedan följer en lista över populära versioner och deras viktigaste funktioner:
- ActivePython
Installationsprogram med kompatibilitet för flera plattformar, dokumentation, PyWin32
- Anaconda
Populära vetenskapliga moduler (t.ex. numpy, scipy och pandas) och pakethanteraren
conda
.- Enthought Deployment Manager
”Nästa generations Python-miljö och pakethanterare”.
Tidigare tillhandahöll Enthought Canopy, men det nådde slutet av sin livslängd 2016.
- WinPython
Windows-specifik distribution med förbyggda vetenskapliga paket och verktyg för att bygga paket.
Observera att dessa paket kanske inte innehåller de senaste versionerna av Python eller andra bibliotek och att de inte underhålls eller stöds av Pythons kärnteam.
4.5. Windows-versioner som stöds¶
Som anges i PEP 11, stöder en Python-version endast en Windows-plattform medan Microsoft anser att plattformen har utökat stöd. Detta innebär att Python 3.14 stöder Windows 10 och nyare. Om du behöver stöd för Windows 7, installera Python 3.8. Om du behöver stöd för Windows 8.1, installera Python 3.12.
4.6. Ta bort begränsningen MAX_PATH¶
Windows har historiskt sett begränsat sökvägslängder till 260 tecken. Detta innebar att sökvägar som var längre än så inte kunde lösas upp och fel uppstod.
I de senaste versionerna av Windows kan denna begränsning utökas till över 32.000 tecken. Din administratör måste aktivera grupprincipen ”Enable Win32 long paths” eller ange LongPathsEnabled
till 1
i registernyckeln HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
.
Detta gör att funktionen open()
, modulen os
och de flesta andra sökvägsfunktioner kan acceptera och returnera sökvägar som är längre än 260 tecken.
När du har ändrat ovanstående alternativ och startat om krävs ingen ytterligare konfiguration.
4.7. UTF-8-läge¶
Tillagd i version 3.7.
Windows använder fortfarande äldre kodningar för systemkodningen (ANSI-kodsidan). Python använder den för standardkodningen av textfiler (t.ex. locale.getencoding()
).
Detta kan orsaka problem eftersom UTF-8 används i stor utsträckning på Internet och i de flesta Unix-system, inklusive WSL (Windows Subsystem for Linux).
Du kan använda Python UTF-8 Mode för att ändra standardkodningen för text till UTF-8. Du kan aktivera Python UTF-8 Mode via kommandoradsalternativet -X utf8
eller miljövariabeln PYTHONUTF8=1
. Se PYTHONUTF8
för att aktivera UTF-8-läget och Pythons installationshanterare för hur du ändrar miljövariabler.
När Python UTF-8 Mode är aktiverat kan du fortfarande använda systemkodningen (ANSI Code Page) via codec:en ”mbcs”.
Observera att om du lägger till PYTHONUTF8=1
till standardmiljövariablerna kommer det att påverka alla Python 3.7+-program på ditt system. Om du har några Python 3.7+-program som förlitar sig på den äldre systemkodningen rekommenderas det att du ställer in miljövariabeln tillfälligt eller använder kommandoradsalternativet -X utf8
.
Anteckning
Även när UTF-8-läget är avaktiverat använder Python UTF-8 som standard i Windows:
Konsol-I/O inklusive standard-I/O (se PEP 528 för detaljer).
filsystemskodning (se PEP 529 för detaljer).
4.8. Hitta moduler¶
Dessa anteckningar kompletterar beskrivningen i Initialisering av sökvägen för modulen sys.path med detaljerade Windows-anteckningar.
När ingen ._pth
-fil hittas är det så här sys.path
fylls i under Windows:
En tom post läggs till i början, vilket motsvarar den aktuella katalogen.
Om miljövariabeln
PYTHONPATH
finns, enligt beskrivningen i Miljövariabler, läggs dess poster till härnäst. Observera att i Windows måste sökvägar i den här variabeln separeras med semikolon för att skilja dem från kolon som används i enhetsidentifierare (C:\
etc.).Ytterligare ”programsökvägar” kan läggas till i registret som undernycklar till
\SOFTWARE\Python\PythonCore{version}\PythonPath
under bådeHKEY_CURRENT_USER
ochHKEY_LOCAL_MACHINE
. Undernycklar som har semikolonavgränsade söksträngar som standardvärde kommer att leda till att varje sökväg läggs till isys.path
. (Observera att alla kända installationsprogram endast använder HKLM, så HKCU är vanligtvis tom)Om miljövariabeln
PYTHONHOME
är inställd, antas den vara ”Python Home”. Annars används sökvägen till den huvudsakliga Python-körbara filen för att hitta en ”landmärkesfil” (antingenLib\os.py
ellerpythonXY.zip
) för att härleda ”Python Home”. Om ett Python-hem hittas baseras de relevanta underkatalogerna som läggs till isys.path
(Lib
,plat-win
, etc) på den mappen. I annat fall konstrueras Pythons huvudsökväg från PythonPath som lagras i registret.Om Python Home inte kan hittas, ingen
PYTHONPATH
anges i miljön och inga registerposter kan hittas, används en standardsökväg med relativa poster (t.ex..\Lib;.\plat-win
, etc.).
Om filen pyvenv.cfg
hittas tillsammans med den körbara huvudfilen eller i katalogen en nivå ovanför den körbara filen, gäller följande variationer:
Om
home
är en absolut sökväg ochPYTHONHOME
inte har angetts, används denna sökväg i stället för sökvägen till den huvudsakliga körbara filen när hemplatsen räknas ut.
Slutresultatet av allt detta är:
När du kör
python.exe
, eller någon annan .exe i huvudkatalogen för Python (antingen en installerad version eller direkt från PCbuild-katalogen), härleds kärnsökvägen och kärnsökvägarna i registret ignoreras. Andra ”applikationssökvägar” i registret läses alltid.När Python finns i en annan .exe (annan katalog, inbäddad via COM, etc), kommer ”Python Home” inte att kunna härledas, så kärnvägen från registret används. Andra ”applikationssökvägar” i registret läses alltid.
Om Python inte kan hitta sitt hem och det inte finns något registervärde (frusen .exe, någon mycket konstig installationskonfiguration) får du en sökväg med några standardiserade, men relativa, sökvägar.
För dem som vill paketera Python i sin applikation eller distribution, kommer följande råd att förhindra konflikter med andra installationer:
Lägg till en
._pth
-fil tillsammans med din körbara fil som innehåller de kataloger som ska inkluderas. Detta kommer att ignorera sökvägar som anges i registret och miljövariabler, och även ignorerasite
om inteimport site
anges.Om du laddar
python3.dll
ellerpython37.dll
i din egen körbara fil, ange uttryckligenPyConfig.module_search_paths
förePy_InitializeFromConfig()
.Rensa och/eller skriv över
PYTHONPATH
och ställ inPYTHONHOME
innan du startarpython.exe
från ditt program.Om du inte kan använda de föregående förslagen (t.ex. om du är en distribution som tillåter att man kör
python.exe
direkt), se till att filen med landmärket (Lib\os.py
) finns i installationskatalogen. (Observera att den inte kommer att upptäckas i en ZIP-fil, men en korrekt namngiven ZIP-fil kommer att upptäckas istället)
Detta säkerställer att filerna i en systemomfattande installation inte får företräde framför den kopia av standardbiblioteket som levereras med ditt program. Annars kan dina användare få problem med att använda din applikation. Observera att det första förslaget är det bästa, eftersom de andra fortfarande kan vara känsliga för icke-standardiserade sökvägar i registret och användarnas webbplatspaket.
Ändrad i version 3.6: Lägg till filstöd för ._pth
och ta bort alternativet applocal
från pyvenv.cfg
.
Ändrad i version 3.6: Lägg till pythonXX.zip
som ett potentiellt landmärke i direkt anslutning till den körbara filen.
Föråldrad sedan version 3.6: Moduler som anges i registret under Modules
(inte PythonPath
) kan importeras av importlib.machinery.WindowsRegistryFinder
. Denna sökare är aktiverad i Windows i 3.6.0 och tidigare, men kan behöva läggas till explicit i sys.meta_path
i framtiden.
4.9. Ytterligare moduler¶
Även om Python strävar efter att vara portabelt mellan alla plattformar finns det funktioner som är unika för Windows. Det finns ett par moduler, både i standardbiblioteket och externa, och snuttar för att använda dessa funktioner.
De Windows-specifika standardmodulerna finns dokumenterade i MS Windows-specifika tjänster.
4.9.1. PyWin32¶
Modulen PyWin32 av Mark Hammond är en samling moduler för avancerat Windows-specifikt stöd. Detta inkluderar verktyg för:
Component Object Model (COM)
Win32 API-anrop
Register
Händelselogg
Microsoft Foundation Classes (MFC) användargränssnitt
PythonWin är ett exempel på en MFC-applikation som levereras med PyWin32. Det är en inbäddningsbar IDE med en inbyggd debugger.
Se även
- Win32 Hur gör jag…?
av Tim Golden
- Python och COM
av David och Paul Boddie
4.9.2. cx_Freeze¶
cx_Freeze paketerar Python-skript till körbara Windows-program (*.exe
-filer). När du har gjort detta kan du distribuera din applikation utan att kräva att användarna installerar Python.
4.10. Kompilera Python på Windows¶
Om du vill kompilera CPython själv är det första du bör göra att hämta källan. Du kan ladda ner antingen den senaste versionens källa eller bara ta en ny checkout.
Källträdet innehåller en bygglösning och projektfiler för Microsoft Visual Studio, som är den kompilator som används för att bygga de officiella Pythonversionerna. Dessa filer finns i katalogen PCbuild
.
Se PCbuild/readme.txt
för allmän information om byggprocessen.
För tilläggsmoduler, se Bygga C- och C++-tillägg i Windows.
4.11. Det fullständiga installationsprogrammet (föråldrat)¶
Föråldrad sedan version 3.14: Detta installationsprogram är föråldrat sedan 3.14 och kommer inte att produceras för Python 3.16 eller senare. Se Pythons installationshanterare för det moderna installationsprogrammet.
4.11.1. Installationssteg¶
Fyra Python 3.14-installationsprogram finns tillgängliga för nedladdning - två vardera för 32-bitars- och 64-bitarsversionerna av tolken. Webbinstallationsprogrammet är en liten första nedladdning och hämtar automatiskt de nödvändiga komponenterna efter behov. Installationsprogrammet offline innehåller de komponenter som behövs för en standardinstallation och kräver endast en internetanslutning för tillvalsfunktioner. Se Installera utan att ladda ner för andra sätt att undvika nedladdning under installationen.
Efter att installationsprogrammet har startats kan ett av två alternativ väljas:

Om du väljer ”Installera nu”:
Du behöver inte vara administratör (såvida inte en systemuppdatering för C Runtime Library krävs eller om du installerar Pythons installationshanterare för alla användare)
Python kommer att installeras i din användarkatalog
Pythons installationshanterare kommer att installeras enligt alternativet längst ner på första sidan
Standardbiblioteket, testsviten, startprogrammet och pip kommer att installeras
Om du väljer detta läggs installationskatalogen till i din
PATH
Genvägar kommer endast att vara synliga för den aktuella användaren
Om du väljer ”Customize installation” kan du välja vilka funktioner som ska installeras, installationsplatsen och andra alternativ eller åtgärder efter installationen. Om du vill installera felsökningssymboler eller binärfiler måste du använda det här alternativet.
För att utföra en installation för alla användare bör du välja ”Anpassa installationen”. I det här fallet:
Du kan behöva uppge administrativa referenser eller godkännande
Python kommer att installeras i katalogen Program Files
Pythons installationshanterare kommer att installeras i Windows-katalogen
Tillvalsfunktioner kan väljas under installationen
Standardbiblioteket kan förkompileras till bytekod
Om detta väljs kommer installationskatalogen att läggas till i systemet
PATH
Genvägar är tillgängliga för alla användare
4.11.2. Ta bort begränsningen MAX_PATH¶
Windows har historiskt sett begränsat sökvägslängder till 260 tecken. Detta innebar att sökvägar som var längre än så inte kunde lösas upp och fel uppstod.
I de senaste versionerna av Windows kan denna begränsning utökas till cirka 32.000 tecken. Din administratör måste aktivera grupprincipen ”Enable Win32 long paths” eller ange LongPathsEnabled
till 1
i registernyckeln HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
.
Detta gör att funktionen open()
, modulen os
och de flesta andra sökvägsfunktioner kan acceptera och returnera sökvägar som är längre än 260 tecken.
När du har ändrat ovanstående alternativ krävs ingen ytterligare konfiguration.
Ändrad i version 3.6: Stöd för långa sökvägar har aktiverats i Python.
4.11.3. Installera utan användargränssnitt¶
Alla alternativ som är tillgängliga i installationsgränssnittet kan också anges från kommandoraden, vilket gör att skriptbaserade installationsprogram kan replikera en installation på många maskiner utan att användaren behöver ingripa. Dessa alternativ kan också ställas in utan att undertrycka användargränssnittet för att ändra några av standardvärdena.
Följande alternativ (som hittas genom att exekvera installationsprogrammet med /?
) kan skickas till installationsprogrammet:
Namn |
Beskrivning |
---|---|
/passive |
för att visa framsteg utan att kräva användarinteraktion |
/quiet |
för att installera/avinstallera utan att visa något användargränssnitt |
/simple |
för att förhindra användaranpassning |
/uninstall |
för att ta bort Python (utan bekräftelse) |
/layout [katalog] |
för att ladda ner alla komponenter |
/log [filnamn] |
för att ange loggfilernas plats |
Alla andra alternativ skickas som name=value
, där värdet vanligtvis är 0
för att inaktivera en funktion, 1
för att aktivera en funktion eller en sökväg. Den fullständiga listan över tillgängliga alternativ visas nedan.
Namn |
Beskrivning |
Standard |
---|---|---|
InstallAllUsers |
Utför en systemomfattande installation. |
0 |
TargetDir |
Installationskatalogen |
Vald baserat på InstallAllUsers |
DefaultAllUsersTargetDir |
Standardinstallationskatalogen för installationer för alla användare |
|
DefaultJustForMeTargetDir |
Standardinstallationskatalogen för just-for-me-installationer |
|
DefaultCustomTargetDir |
Den standardkatalog för anpassad installation som visas i användargränssnittet |
(tomt) |
AssociateFiles |
Skapa filassociationer om startprogrammet också är installerat. |
1 |
CompileAll |
Kompilera alla |
0 |
PrependPath |
Lägg till install- och Scripts-katalogerna i |
0 |
AppendPath |
Lägg till install- och Scripts-katalogerna i |
0 |
Genvägar |
Skapa genvägar till tolken, dokumentationen och IDLE om det finns installerat. |
1 |
Include_doc |
Installera Python-manualen |
1 |
Include_debug |
Installera felsökningsbinärfiler |
0 |
Include_dev |
Installera utvecklingshuvuden och bibliotek. Om du utelämnar detta kan det leda till en oanvändbar installation. |
1 |
Include_exe |
Installera |
1 |
Include_launcher |
Installera Pythons installationshanterare. |
1 |
Installera startprogram Alla användare |
Installerar startprogrammet för alla användare. Kräver också att |
1 |
Include_lib |
Installera standardbibliotek och tilläggsmoduler. Om du utelämnar detta kan det leda till en oanvändbar installation. |
1 |
Include_pip |
Installera medföljande pip och setuptools |
1 |
Include_symbols |
Installera felsökningssymboler ( |
0 |
Include_tcltk |
Installera Tcl/Tk-stöd och IDLE |
1 |
Include_test |
Installera testsviten för standardbiblioteket |
1 |
Include_tools |
Installera verktygsskript |
1 |
LauncherOnly |
Installerar endast startprogrammet. Detta kommer att åsidosätta de flesta andra alternativ. |
0 |
SimpleInstall |
Inaktivera de flesta installationsgränssnitt |
0 |
SimpleInstallDescription |
Ett anpassat meddelande som ska visas när det förenklade installationsgränssnittet används. |
(tomt) |
Om du t.ex. vill installera en systemomfattande Python-installation som standard kan du använda följande kommando (från en kommandotolk med förhöjd nivå):
python-3.9.0.exe /quiet InstallAllUsers=1 PrependPath=1 Include_test=0
För att användare enkelt ska kunna installera en personlig kopia av Python utan testsviten kan du tillhandahålla en genväg med följande kommando. Detta kommer att visa en förenklad startsida och inte tillåta anpassning:
python-3.9.0.exe InstallAllUsers=0 Include_launcher=0 Include_test=0
SimpleInstall=1 SimpleInstallDescription="Bara för mig, ingen testsvit."
(Observera att om du utelämnar startprogrammet utelämnas även filassociationer, och det rekommenderas endast för installationer per användare när det också finns en systemomfattande installation som inkluderade startprogrammet)
De alternativ som anges ovan kan också anges i en fil med namnet unattend.xml
vid sidan av den körbara filen. Denna fil innehåller en lista med alternativ och värden. När ett värde anges som ett attribut konverteras det till ett tal om det är möjligt. Värden som anges som elementtext lämnas alltid som strängar. I den här exempelfilen anges samma alternativ som i det föregående exemplet:
<Options>
<Option Name="InstallAllUsers" Value="no" />
<Option Name="Include_launcher" Value="0" />
<Option Name="Include_test" Value="no" />
<Option Name="SimpleInstall" Value="yes" />
<Option Name="SimpleInstallDescription">Bara för mig, ingen testsvit</Option>
</Options>
4.11.4. Installera utan att ladda ner¶
Eftersom vissa funktioner i Python inte ingår i den första nedladdningen av installationsprogrammet kan det krävas en internetanslutning för att välja dessa funktioner. För att undvika detta kan alla möjliga komponenter laddas ner på begäran för att skapa en komplett layout som inte längre kräver en internetanslutning oavsett vilka funktioner som väljs. Observera att denna nedladdning kan vara större än nödvändigt, men om ett stort antal installationer ska utföras är det mycket användbart att ha en lokalt cachad kopia.
Kör följande kommando från Kommandotolken för att ladda ner alla filer som krävs. Kom ihåg att ersätta python-3.9.0.exe
med det faktiska namnet på ditt installationsprogram och att skapa layouter i egna kataloger för att undvika kollisioner mellan filer med samma namn.
python-3.9.0.exe /layout [valfri målkatalog]
Du kan också ange alternativet /quiet
för att dölja förloppsvisningen.
4.11.5. Modifiera en installation¶
När Python har installerats kan du lägga till eller ta bort funktioner via verktyget Program och funktioner som ingår i Windows. Markera Python-posten och välj ”Avinstallera/ändra” för att öppna installationsprogrammet i underhållsläge.
med ”Modify” kan du lägga till eller ta bort funktioner genom att ändra kryssrutorna - oförändrade kryssrutor installerar eller tar inte bort något. Vissa alternativ kan inte ändras i detta läge, till exempel installationskatalogen; för att ändra dessa måste du ta bort och sedan installera om Python helt och hållet.
”Repair” kontrollerar alla filer som ska installeras med de aktuella inställningarna och ersätter alla filer som har tagits bort eller ändrats.
”Avinstallera” tar bort Python helt och hållet, med undantag för Pythons installationshanterare, som har en egen post i Program och funktioner.
4.11.6. Installera fritt trådade binärfiler¶
Tillagd i version 3.13: (Experimentell)
Anteckning
Allt som beskrivs i det här avsnittet betraktas som experimentellt och kan förväntas ändras i framtida versioner.
För att installera förbyggda binärfiler med aktiverad free-threading (se PEP 703), bör du välja ”Anpassa installationen”. På den andra sidan med alternativ finns kryssrutan ”Download free-threaded binaries”.

Om du väljer det här alternativet hämtas och installeras ytterligare binärfiler på samma plats som huvudinstallationen av Python. Den huvudsakliga körbara filen heter python3.13t.exe
, och andra binärfiler får antingen suffixet t
eller ett fullständigt ABI-suffix. Pythons källfiler och medföljande tredjepartsberoenden delas med huvudinstallationen.
Den frittrådade versionen är registrerad som en vanlig Python-installation med taggen 3.13t
(med suffixet -32
eller -arm64
som normalt för dessa plattformar). Detta gör det möjligt för verktyg att upptäcka den och för Pythons installationshanterare att stödja py.exe -3.13t
. Observera att startprogrammet kommer att tolka py.exe -3
(eller en python3
shebang) som ”den senaste 3.x-installationen”, vilket kommer att föredra de frittrådade binärerna framför de vanliga, medan py.exe -3.13
inte kommer att göra det. Om du använder den korta typen av alternativ kanske du föredrar att inte installera de fritt trådade binärerna just nu.
Om du vill ange installationsalternativet på kommandoraden använder du Include_freethreaded=1
. Se Installera utan att ladda ner för instruktioner om hur du i förväg laddar ner de extra binärerna för offlineinstallation. Alternativen för att inkludera debug-symboler och binärfiler gäller även för free-threaded-byggnationer.
Fritt trådade binärfiler finns också tillgängliga på nuget.org.
4.12. Python Launcher för Windows (Föråldrad)¶
Föråldrad sedan version 3.14: Startprogrammet och den här dokumentationen har ersatts av Python Install Manager som beskrivs ovan. Detta bevaras temporärt för historiskt intresse.
Tillagd i version 3.3.
Python Launcher för Windows är ett verktyg som hjälper till att hitta och köra olika Python-versioner. Det gör det möjligt för skript (eller kommandoraden) att ange en preferens för en specifik Python-version, och kommer att lokalisera och köra den versionen.
Till skillnad från variabeln PATH
kommer startprogrammet att korrekt välja den lämpligaste versionen av Python. Den föredrar installationer per användare framför systemomfattande installationer och beställer efter språkversion i stället för att använda den senast installerade versionen.
Startrampen specificerades ursprungligen i PEP 397.
4.12.1. Kom igång¶
4.12.1.1. Från kommandoraden¶
Ändrad i version 3.6.
Systemomfattande installationer av Python 3.3 och senare kommer att placera startprogrammet på din PATH
. Startprogrammet är kompatibelt med alla tillgängliga versioner av Python, så det spelar ingen roll vilken version som är installerad. För att kontrollera att startprogrammet är tillgängligt, kör följande kommando i Kommandotolken:
py
Du bör se att den senaste versionen av Python som du har installerat startas - den kan avslutas på normalt sätt och eventuella ytterligare kommandoradsargument som anges skickas direkt till Python.
Om du har flera versioner av Python installerade (t.ex. 3.7 och 3.14) kommer du att ha märkt att Python 3.14 startades - för att starta Python 3.7, prova kommandot:
py -3,7
Om du vill ha den senaste versionen av Python 2 som du har installerat, prova kommandot:
py -2
Om du får följande felmeddelande har du inte installerat startprogrammet:
'py' känns inte igen som ett internt eller externt kommando,
operativt program eller batchfil.
Kommandot:
py --list
visar den eller de versioner av Python som för närvarande är installerade.
Argumentet -x.y
är kortformen av argumentet -V:Company/Tag
, som gör det möjligt att välja en specifik Python-körtid, inklusive de som kan ha kommit från någon annanstans än python.org. Alla körtider som registreras genom att följa PEP 514 kommer att kunna hittas. Kommandot --list
listar alla tillgängliga runtimes i formatet -V:
.
När du använder argumentet -V:
begränsas urvalet till runtimes från den leverantören om du anger Company, medan urvalet begränsas till alla leverantörer om du bara anger Tag. Observera att om snedstrecket utelämnas innebär det en tagg:
# Välj alla "3.*" taggade runtime
py -V:3
# Välj alla 'PythonCore'-utgivna körtider
py -V:PythonCore/
# Välj PythonCores senaste Python 3-körtid
py -V:PythonCore/3
Den korta formen av argumentet (-3
) väljer alltid bara från Pythons kärnversioner och inte från andra distributioner. Den längre formen (-V:3
) kommer dock att välja från alla.
Företaget matchas på hela strängen, utan hänsyn till skiftlägeskänslighet. Taggen matchas antingen med hela strängen eller med ett prefix, förutsatt att nästa tecken är en punkt eller ett bindestreck. Detta gör att -V:3.1
kan matcha 3.1-32
, men inte 3.10
. Taggar sorteras med hjälp av numerisk ordning (3.10
är nyare än 3.1
), men jämförs med hjälp av text (-V:3.01
matchar inte 3.1
).
4.12.1.2. Virtuella miljöer¶
Tillagd i version 3.5.
Om startprogrammet körs utan någon explicit specifikation av Python-versionen och en virtuell miljö (skapad med standardbibliotekets modul venv
eller det externa verktyget virtualenv
) är aktiv, kommer startprogrammet att köra den virtuella miljöns tolk istället för den globala. Om du vill köra den globala tolken måste du antingen inaktivera den virtuella miljön eller uttryckligen ange den globala Python-versionen.
4.12.1.3. Från ett skript¶
Låt oss skapa ett test-Python-skript - skapa en fil som heter hello.py
med följande innehåll
#! python
import sys
sys.stdout.write("hej från Python %s\n" % (sys.version,))
Från den katalog där hello.py finns, kör kommandot:
py hello.py
Du bör märka att versionsnumret för din senaste Python 2.x-installation skrivs ut. Försök nu att ändra den första raden till att vara:
#! python3
Om kommandot körs igen skrivs nu den senaste Python 3.x-informationen ut. Precis som med kommandoradsexemplen ovan kan du ange en mer explicit versionskvalificerare. Om du antar att du har Python 3.7 installerat kan du ändra första raden till #! python3.7
så kommer du att få information om version 3.7 utskriven.
Observera att till skillnad från interaktiv användning kommer en ren ”python” att använda den senaste versionen av Python 2.x som du har installerat. Detta är för bakåtkompatibilitet och för kompatibilitet med Unix, där kommandot python
vanligtvis hänvisar till Python 2.
4.12.1.4. Från filassociationer¶
Startprogrammet bör ha associerats med Python-filer (d.v.s. .py
, .pyw
, .pyc
-filer) när det installerades. Detta innebär att när du dubbelklickar på en av dessa filer från Windows Explorer kommer startprogrammet att användas, och därför kan du använda samma möjligheter som beskrivs ovan för att få skriptet att ange vilken version som ska användas.
Den viktigaste fördelen med detta är att en enda startprogram kan stödja flera Python-versioner samtidigt beroende på innehållet i den första raden.
4.12.2. Shebang-rader¶
Om den första raden i en skriptfil börjar med #!
kallas den för en ”shebang”-rad. Linux och andra Unix-liknande operativsystem har inbyggt stöd för sådana rader och de används ofta i sådana system för att ange hur ett skript ska köras. Med den här startprogrammet kan samma funktioner användas med Python-skript på Windows och exemplen ovan visar hur de används.
För att shebang-rader i Python-skript ska kunna portas mellan Unix och Windows stöder den här startprogrammet ett antal ”virtuella” kommandon för att ange vilken tolk som ska användas. De virtuella kommandon som stöds är:
/usr/bin/env
/usr/bin/python
/usr/local/bin/python
python
Om till exempel den första raden i ditt skript börjar med
#! /usr/bin/python
Standard-Python eller en aktiv virtuell miljö kommer att hittas och användas. Eftersom många Python-skript som skrivits för att fungera på Unix redan har den här raden, bör du upptäcka att dessa skript kan användas av startprogrammet utan modifiering. Om du skriver ett nytt skript på Windows som du hoppas ska vara användbart på Unix, bör du använda en av shebang-raderna som börjar med /usr
.
Alla ovanstående virtuella kommandon kan kompletteras med en explicit version (antingen bara huvudversionen eller huvud- och minoritetsversionen). Dessutom kan 32-bitarsversionen begäras genom att lägga till ”-32” efter minor-versionen. Dvs. /usr/bin/python3.7-32
kommer att begära användning av 32-bitars Python 3.7. Om en virtuell miljö är aktiv kommer versionen att ignoreras och miljön kommer att användas.
Tillagd i version 3.7: Från och med Python Launcher 3.7 är det möjligt att begära en 64-bitarsversion med suffixet ”-64”. Dessutom är det möjligt att ange major och arkitektur utan minor (t.ex. /usr/bin/python3-64
).
Ändrad i version 3.11: Suffixet ”-64” är föråldrat och innebär nu ”alla arkitekturer som inte bevisligen är i386/32-bit”. För att begära en specifik miljö, använd det nya -V:TAG
-argumentet med den fullständiga taggen.
Ändrad i version 3.13: Virtuella kommandon som refererar till python
föredrar nu en aktiv virtuell miljö istället för att söka i PATH
. Detta hanterar fall där shebang specificerar /usr/bin/env python3
men python3.exe
inte finns i den aktiva miljön.
Formen /usr/bin/env
av shebang-raden har ytterligare en speciell egenskap. Innan den här formen letar efter installerade Python-tolkar kommer den att söka i den körbara PATH
efter en Python-körbar som matchar det namn som anges som första argument. Detta motsvarar beteendet hos Unix-programmet env
, som utför en sökning i PATH
. Om en körbar fil som matchar det första argumentet efter kommandot env
inte kan hittas, men argumentet börjar med python
, kommer det att hanteras på samma sätt som beskrivs för de andra virtuella kommandona. Miljövariabeln PYLAUNCHER_NO_SEARCH_PATH
kan sättas (till valfritt värde) för att hoppa över sökningen i PATH
.
Shebang-rader som inte matchar något av dessa mönster söks upp i avsnittet [commands]
i startprogrammets .INI-fil. Detta kan användas för att hantera vissa kommandon på ett sätt som är vettigt för ditt system. Namnet på kommandot måste vara ett enda argument (inga mellanslag i den körbara shebang-filen) och det värde som ersätts är den fullständiga sökvägen till den körbara filen (ytterligare argument som anges i .INI-filen kommer att citeras som en del av filnamnet).
[commands]
/bin/xpython=C:\Program Files\XPython\python.exe
Alla kommandon som inte finns i INI-filen behandlas som Windows körbara sökvägar som är absoluta eller relativa till den katalog som innehåller skriptfilen. Detta är en bekvämlighet för skript som bara finns i Windows, t.ex. de som genereras av ett installationsprogram, eftersom beteendet inte är kompatibelt med skal i Unix-stil. Dessa sökvägar kan citeras och kan innehålla flera argument, varefter sökvägen till skriptet och eventuella ytterligare argument läggs till.
4.12.3. Argument i shebang-rader¶
Shebang-raderna kan också ange ytterligare alternativ som ska skickas till Python-tolken. Till exempel, om du har en shebang-rad:
#! /usr/bin/python -v
Då kommer Python att startas med alternativet -v
4.12.4. Anpassning¶
4.12.4.1. Anpassning via INI-filer¶
Två .ini-filer kommer att genomsökas av startprogrammet - py.ini
i den aktuella användarens programdatakatalog (%LOCALAPPDATA%
eller $env:LocalAppData
) och py.ini
i samma katalog som startprogrammet. Samma .ini-filer används både för konsolversionen av startprogrammet (dvs. py.exe) och för Windowsversionen (dvs. pyw.exe).
Anpassningar som anges i ”applikationskatalogen” kommer att ha företräde framför den som ligger bredvid den körbara filen, så att en användare som kanske inte har skrivrättigheter till .ini-filen bredvid startprogrammet kan åsidosätta kommandon i den globala .ini-filen.
4.12.4.2. Anpassa standardversioner av Python¶
I vissa fall kan en versionskvalificerare inkluderas i ett kommando för att diktera vilken version av Python som ska användas av kommandot. En versionskvalificerare börjar med ett huvudversionsnummer och kan eventuellt följas av en punkt (’.’) och en mindre versionsspecificerare. Dessutom är det möjligt att ange om en 32- eller 64-bitars implementering ska begäras genom att lägga till ”-32” eller ”-64”.
Till exempel har en shebang-rad med #!python
ingen versionskvalifierare, medan #!python3
har en versionskvalifierare som endast anger en huvudversion.
Om inga versionskvalificerare finns i ett kommando kan miljövariabeln PY_PYTHON
anges för att ange standardversionskvalificeraren. Om den inte anges är standardvärdet ”3”. Variabeln kan ange vilket värde som helst som kan anges på kommandoraden, t.ex. ”3”, ”3.7”, ”3.7-32” eller ”3.7-64”. (Observera att alternativet ”-64” endast är tillgängligt med startprogrammet som ingår i Python 3.7 eller nyare)
Om inga mindre versionskvalificerare hittas kan miljövariabeln PY_PYTHON{major}
(där {major}
är den aktuella huvudversionskvalificeraren enligt ovan) anges för att ange den fullständiga versionen. Om inget sådant alternativ hittas kommer startprogrammet att räkna upp de installerade Python-versionerna och använda den senaste mindre versionen som hittats för huvudversionen, vilket troligen, men inte garanterat, är den senast installerade versionen i den familjen.
På 64-bitars Windows med både 32-bitars och 64-bitars implementationer av samma (major.minor) Python-version installerad, kommer 64-bitarsversionen alltid att föredras. Detta gäller för både 32-bitars och 64-bitars implementationer av startprogrammet - ett 32-bitars startprogram kommer att föredra att köra en 64-bitars Python-installation av den angivna versionen om den är tillgänglig. Detta är för att man ska kunna förutsäga startprogrammets beteende när man bara vet vilka versioner som är installerade på datorn och utan hänsyn till i vilken ordning de installerades (dvs. utan att veta om en 32- eller 64-bitarsversion av Python och motsvarande startprogram installerades sist). Som nämnts ovan kan ett valfritt suffix ”-32” eller ”-64” användas på en versionsangivelse för att ändra detta beteende.
Exempel:
Om inga relevanta alternativ har angetts kommer kommandona
python
ochpython2
att använda den senaste Python 2.x-versionen som finns installerad och kommandotpython3
kommer att använda den senaste Python 3.x-versionen som finns installerad.Kommandot
python3.7
kommer inte att fråga efter några alternativ alls eftersom versionerna är fullständigt specificerade.Om
PY_PYTHON=3
, kommer kommandonapython
ochpython3
båda att använda den senaste installerade Python 3-versionen.Om
PY_PYTHON=3.7-32
, kommer kommandotpython
att använda 32-bitars implementationen av 3.7 medan kommandotpython3
kommer att använda den senaste installerade Python (PY_PYTHON beaktades inte alls eftersom en huvudversion angavs)Om
PY_PYTHON=3
ochPY_PYTHON3=3.7
, kommer kommandonapython
ochpython3
båda att använda specifikt 3.7
Förutom miljövariabler kan samma inställningar konfigureras i INI-filen som används av startprogrammet. Avsnittet i INI-filen heter [defaults]
och nyckelnamnet kommer att vara detsamma som miljövariablerna utan det inledande prefixet PY_
(och observera att nyckelnamnen i INI-filen inte är skiftlägeskänsliga.) Innehållet i en miljövariabel kommer att åsidosätta sådant som anges i INI-filen.
Till exempel:
Att ställa in
PY_PYTHON=3.7
är likvärdigt med INI-filen som innehåller:
[defaults]
python=3.7
Att ställa in
PY_PYTHON=3
ochPY_PYTHON3=3.7
är likvärdigt med att INI-filen innehåller:
[defaults]
python=3
python3=3.7
4.12.5. Diagnostik¶
Om miljövariabeln PYLAUNCHER_DEBUG
är inställd (på vilket värde som helst) kommer startprogrammet att skriva ut diagnostisk information till stderr (dvs. till konsolen). Även om denna information lyckas vara både utförlig och kortfattad, bör den göra det möjligt för dig att se vilka versioner av Python som hittades, varför en viss version valdes och den exakta kommandoraden som användes för att köra mål-Python. Den är i första hand avsedd för testning och felsökning.
4.12.6. Torrkörning¶
Om miljövariabeln PYLAUNCHER_DRYRUN
är inställd (på vilket värde som helst) kommer startprogrammet att skriva ut kommandot som det skulle ha kört, men inte starta Python. Detta kan vara användbart för verktyg som vill använda startprogrammet för att upptäcka och sedan starta Python direkt. Observera att kommandot som skrivs till standardutmatningen alltid är kodat med UTF-8 och kanske inte visas korrekt i konsolen.
4.12.7. Installera på begäran¶
Om miljövariabeln PYLAUNCHER_ALLOW_INSTALL
är inställd (på valfritt värde) och den begärda Python-versionen inte är installerad men finns tillgänglig i Microsoft Store, kommer startprogrammet att försöka installera den. Detta kan kräva användarinteraktion för att slutföras, och du kan behöva köra kommandot igen.
En extra PYLAUNCHER_ALWAYS_INSTALL
-variabel gör att startprogrammet alltid försöker installera Python, även om det upptäcks. Detta är främst avsett för testning (och bör användas med PYLAUNCHER_DRYRUN
).
4.12.8. Returkoder¶
Följande utgångskoder kan returneras av Python-startprogrammet. Tyvärr finns det inget sätt att skilja dessa från utgångskoden för Python själv.
Namnen på koderna är de som används i källorna och är endast avsedda som referens. Det finns inget sätt att få tillgång till eller lösa dem förutom att läsa denna sida. Posterna är listade i alfabetisk ordning efter namn.
Namn |
Värde |
Beskrivning |
---|---|---|
RC_BAD_VENV_CFG |
107 |
En |
RC_CREATE_PROCESS |
101 |
Lyckades inte starta Python. |
RC_INSTALLING |
111 |
En installation startades, men kommandot måste köras igen efter att den har slutförts. |
RC_INTERNAL_ERROR |
109 |
Oväntat fel. Rapportera en bugg. |
RC_NO_COMMANDLINE |
108 |
Det går inte att hämta kommandoraden från operativsystemet. |
RC_NO_PYTHON |
103 |
Det gick inte att hitta den begärda versionen. |
RC_NO_VENV_CFG |
106 |
En |