django-admin och manage.pyLink to this heading#django-admin är Djangos kommandoradsverktyg för administrativa uppgifter. Detta dokument beskriver allt det kan göra.
Dessutom skapas manage.py automatiskt i varje Django-projekt. Den gör samma sak som django-admin men ställer också in miljövariabeln DJANGO_SETTINGS_MODULE så att den pekar på ditt projekts settings.py-fil.
Skriptet django-admin bör finnas på din systemsökväg om du installerade Django via pip. Om det inte finns i din sökväg, se till att du har aktiverat din virtuella miljö.
När du arbetar med ett enda Django-projekt är det i allmänhet lättare att använda manage.py än django-admin. Om du behöver växla mellan flera Django-inställningsfiler, använd django-admin med DJANGO_SETTINGS_MODULE eller kommandoradsalternativet --settings.
I kommandoradsexemplen i det här dokumentet används django-admin för att vara konsekvent, men alla exempel kan lika gärna använda manage.py eller python -m django.
Linux / macOS
$ django-admin <command> [options]\n$ manage.py <command> [options]\n$ python -m django <command> [options]\nWindows
...\\> django-admin <command> [options]\n...\\> manage.py <command> [options]\n...\\> py -m django <command> [options]\ncommand ska vara ett av de kommandon som listas i detta dokument. options, som är valfritt, ska vara noll eller flera av de alternativ som finns tillgängliga för det angivna kommandot.
Kör django-admin help för att visa användningsinformation och en lista över de kommandon som tillhandahålls av varje program.
Kör django-admin help --commands för att visa en lista över alla tillgängliga kommandon.
Kör django-admin help <command> för att visa en beskrivning av det angivna kommandot och en lista över dess tillgängliga alternativ.
Många kommandon tar emot en lista med ”appnamn” Ett ”appnamn” är basnamnet på det paket som innehåller dina modeller. Om din INSTALLED_APPS till exempel innehåller strängen 'mysite.blog', är appnamnet blog.
Kör django-admin version för att visa den aktuella Django-versionen.
Utdata följer det schema som beskrivs i PEP 440:
\n1.4.dev17026\n1.4a1\n1.4\nAnvänd --verbosity, där det stöds, för att ange mängden meddelande- och felsökningsinformation som django-admin skriver ut till konsolen.
kontrollLink to this heading#Använder systemkontrollramverket för att inspektera hela Django-projektet för vanliga problem.
\nSom standard kommer alla appar att kontrolleras. Du kan kontrollera en delmängd av appar genom att ange en lista med appetiketter som argument:
\ndjango-admin check auth admin myapp\nRamverket för systemkontroller utför många olika typer av kontroller som är kategoriserade med taggar. Du kan använda dessa taggar för att begränsa de kontroller som utförs till att bara omfatta kontroller i en viss kategori. Om du t.ex. bara vill utföra kontroller av modeller och kompatibilitet kör du:
\ndjango-admin check --tag models --tag compatibility\nAnger den databas där kontroller som kräver databasåtkomst ska utföras:
\ndjango-admin check --database default --database other\nSom standard kommer dessa kontroller inte att köras.
\nVisar en lista över alla tillgängliga taggar.
\nAktiverar några ytterligare kontroller som endast är relevanta i en distributionsinställning.
\nDu kan använda detta alternativ i din lokala utvecklingsmiljö, men eftersom din lokala inställningsmodul för utveckling kanske inte har många av dina produktionsinställningar, kommer du förmodligen att vilja rikta kommandot check mot en annan inställningsmodul, antingen genom att ange miljövariabeln DJANGO_SETTINGS_MODULE eller genom att ange alternativet --settings:
django-admin check --deploy --settings=production_settings\nEller så kan du köra det direkt på en produktions- eller staging-distribution för att verifiera att rätt inställningar används (genom att utelämna --settings). Du kan till och med göra det till en del av din integrationstestsvit.
Anger den meddelandenivå som gör att kommandot avslutas med en status som inte är noll. Standard är ERROR.
compilemessagesLink to this heading#Kompilerar .po-filer skapade av makemessages till .mo-filer för användning med det inbyggda gettext-stödet. Se Internationalisering och lokalisering.
Anger den eller de lokala språkversioner som ska bearbetas. Om inget anges bearbetas alla lokala språk.
\nAnger den eller de lokala språkversioner som ska undantas från bearbetning. Om inget anges utesluts inga lokala språk.
\nInkluderar fuzzy translations i kompilerade filer.
\nExempel på användning:
\ndjango-admin compilemessages --locale=pt_BR\ndjango-admin compilemessages --locale=pt_BR --locale=fr -f\ndjango-admin compilemessages -l pt_BR\ndjango-admin compilemessages -l pt_BR -l fr --use-fuzzy\ndjango-admin compilemessages --exclude=pt_BR\ndjango-admin compilemessages --exclude=pt_BR --exclude=fr\ndjango-admin compilemessages -x pt_BR\ndjango-admin compilemessages -x pt_BR -x fr\nIgnorerar kataloger som matchar det angivna glob-stilmönstret. Använd flera gånger för att ignorera fler.
Exempel på användning:
\ndjango-admin compilemessages --ignore=cache --ignore=outdated/*/locale\ncreatecachetableLink to this heading#Skapar cachetabellerna för användning med databasens cache-backend med hjälp av informationen från din inställningsfil. Se Djangos ramverk för cache för mer information.
\nAnger den databas i vilken cachetabellen/-tabellerna ska skapas. Standardvärdet är default.
Skriver ut den SQL som ska köras utan att faktiskt köra den, så att du kan anpassa den eller använda migreringsramverket.
\ndbshellLink to this heading#Kör kommandoradsklienten för den databasmotor som anges i inställningen ENGINE, med de anslutningsparametrar som anges i inställningarna USER, PASSWORD, etc.
För PostgreSQL kör detta kommandoradsklienten `` psql``.
För MySQL körs kommandoradsklienten mysql.
För SQLite körs kommandoradsklienten sqlite3.
För Oracle körs kommandoradsklienten sqlplus.
Detta kommando förutsätter att programmen finns i din PATH så att ett anrop till programnamnet (psql, mysql, sqlite3, sqlplus) hittar programmet på rätt plats. Det finns inget sätt att ange platsen för programmet manuellt.
Anger den databas där ett skal ska öppnas. Standardvärdet är default.
Alla argument som följer en `` —`` avdelare kommer att vidarebefordras till den underliggande kommandoradsklienten. Till exempel:, med PostgreSQL kan du använda kommandot `` psql`` kommandots `` c`` flagga för att köra en rå SQL-fråga direkt:
\nLinux / macOS
$ django-admin dbshell -- -c 'select current_user'\n current_user\n--------------\n postgres\n(1 row)\nWindows
...\\> django-admin dbshell -- -c 'select current_user'\n current_user\n--------------\n postgres\n(1 row)\nPå MySQL/MariaDB kan du göra detta med kommandot mysql flagga -e:
Linux / macOS
$ django-admin dbshell -- -e "select user()"\n+----------------------+\n| user() |\n+----------------------+\n| djangonaut@localhost |\n+----------------------+\nWindows
...\\> django-admin dbshell -- -e "select user()"\n+----------------------+\n| user() |\n+----------------------+\n| djangonaut@localhost |\n+----------------------+\ndifferensinställningarLink to this heading#Visar skillnader mellan den aktuella inställningsfilen och Djangos standardinställningar (eller en annan inställningsfil som anges av --default).
Inställningar som inte finns med i standardinställningarna följs av "###". Standardinställningarna definierar till exempel inte ROOT_URLCONF, så ROOT_URLCONF följs av "###" i utdata från diffsettings.
Visar alla inställningar, även om de har Djangos standardvärde. Sådana inställningar inleds med "###".
Den inställningsmodul som de aktuella inställningarna ska jämföras med. Lämna tom för att jämföra mot Djangos standardinställningar.
\nAnger utdataformat. Tillgängliga värden är hash och unified. hash är standardläget som visar utdata enligt beskrivningen ovan. unified visar utdata som liknar diff -u. Standardinställningar inleds med ett minustecken, följt av den ändrade inställningen som inleds med ett plustecken.
DumpdataLink to this heading#Skickar ut alla data i databasen som är kopplade till de namngivna programmen till standardutdata.
\nOm inget applikationsnamn anges kommer alla installerade applikationer att dumpas.
\nUtdata från dumpdata kan användas som indata för loaddata.
När resultatet av dumpdata sparas som en fil kan den fungera som en fixtur för tester eller som en initial data.
Observera att dumpdata använder standardhanteraren i modellen för att välja vilka poster som ska dumpas. Om du använder en custom manager som standardhanterare och den filtrerar några av de tillgängliga posterna, kommer inte alla objekt att dumpas.
Använder Djangos bashanterare och dumpar poster som annars skulle kunna filtreras eller ändras av en anpassad hanterare.
\nAnger serialiseringsformatet för utdata. Standardvärdet är JSON. Format som stöds listas i Format för serialisering.
\nAnger antalet indragningsutrymmen som ska användas i utdata. Standardvärdet är None som visar alla data på en enda rad.
Förhindrar att specifika program eller modeller (anges i form av app_label.ModelName) dumpas. Om du anger ett modellnamn är det bara den modellen som utesluts, inte hela programmet. Du kan också blanda programnamn och modellnamn.
Om du vill utesluta flera program, skicka --exclude mer än en gång:
django-admin dumpdata --exclude=auth --exclude=contenttypes\nAnger den databas från vilken data ska dumpas. Standardvärdet är default.
Använder modellmetoden natural_key() för att serialisera alla foreign key och many-to-many-relationer till objekt av den typ som definierar metoden. Om du dumpar contrib.auth Permission-objekt eller contrib.contenttypes ContentType-objekt bör du förmodligen använda den här flaggan. Se natural keys-dokumentationen för mer information om detta och nästa alternativ.
Utelämnar primärnyckeln i de serialiserade data för detta objekt eftersom den kan beräknas under deserialiseringen.
\nSkickar endast ut de objekt som anges i en kommaseparerad lista med primärnycklar. Detta är endast tillgängligt vid dumpning av en modell. Som standard matas alla poster i modellen ut.
\nAnger en fil som de serialiserade data ska skrivas till. Som standard går data till standardutdata.
\nNär detta alternativ är inställt och --verbosity är större än 0 (standard), visas en förloppsindikator i terminalen.
Utdatafilen kan komprimeras med något av formaten bz2, gz, lzma eller xz genom att avsluta filnamnet med motsvarande tillägg. Till exempel:, för att mata ut data som en komprimerad JSON-fil:
django-admin dumpdata -o mydata.json.gz\nspolaLink to this heading#Tar bort alla data från databasen och kör om alla postsynkroniseringshanterare. Tabellen över vilka migreringar som har tillämpats rensas inte.
\nOm du hellre vill starta från en tom databas och köra alla migreringar på nytt bör du ta bort och återskapa databasen och sedan köra migrate istället.
Undertrycker alla användarinstruktioner.
\nAnger vilken databas som ska rensas. Standardvärdet är default.
inspectdbLink to this heading#Introspekterar databastabellerna i databasen som pekas ut av inställningen NAME och matar ut en Django-modellmodul (en models.py-fil) till standardutdata.
Du kan välja vilka tabeller eller vyer som ska inspekteras genom att ange deras namn som argument. Om inga argument anges skapas modeller för vyer endast om alternativet --include-views används. Modeller för partitionstabeller skapas på PostgreSQL om alternativet --include-partitions används.
Använd detta om du har en äldre databas som du vill använda Django med. Skriptet kommer att inspektera databasen och skapa en modell för varje tabell i den.
\nSom du kanske förväntar dig kommer de skapade modellerna att ha ett attribut för varje fält i tabellen. Observera att inspectdb har några specialfall i sin fältnamnsutmatning:
Om inspectdb inte kan mappa en kolumns typ till en modellfälttyp, kommer den att använda TextField och infoga Python-kommentaren 'Denna fälttyp är en gissning.' bredvid fältet i den genererade modellen. De fält som identifieras kan bero på appar som listas i INSTALLED_APPS. Till exempel: lägger django.contrib.postgres till igenkänning för flera PostgreSQL-specifika fälttyper.
Om databasens kolumnnamn är ett reserverat Python-ord (som 'pass', 'class' eller 'for'), kommer inspectdb att lägga till '_field' till attributnamnet. Om en tabell till exempel har kolumnen 'for', kommer den genererade modellen att ha fältet 'for_field', med attributet db_column inställt på 'for'. inspectdb kommer att infoga Python-kommentaren 'Fältet döptes om eftersom det var ett reserverat Python-ord.' bredvid fältet.
Den här funktionen är tänkt som en genväg, inte som en slutgiltig modellgenerering. När du har kört den bör du själv titta igenom de genererade modellerna för att göra anpassningar. Framför allt behöver du ändra modellernas ordning så att modeller som hänvisar till andra modeller får rätt ordning.
\nDjango skapar inte standardvärden för databaser när en default anges för ett modellfält. På samma sätt översätts inte databasstandardvärden till standardvärden för modellfält eller upptäcks på något sätt av inspectdb.
Som standard skapar inspectdb ohanterade modeller. Det vill säga, managed = False i modellens Meta-klass säger till Django att inte hantera varje tabells skapande, modifiering och radering. Om du vill tillåta Django att hantera tabellens livscykel måste du ändra alternativet managed till True (eller ta bort det eftersom True är dess standardvärde).
Modeller skapas för materialiserade vyer om --include-views används.
Modeller skapas för utländska tabeller.
Modeller skapas för materialiserade vyer om --include-views används.
Modeller skapas för partitionstabeller om --include-partitions används.
Anger vilken databas som ska introspekteras. Standardvärdet är default.
Om detta alternativ anges skapas även modeller för partitioner.
\nEndast stöd för PostgreSQL är implementerat.
\nOm detta alternativ anges skapas även modeller för databasvyer.
\nLadda dataLink to this heading#Söker efter och laddar innehållet i den namngivna fixture i databasen.
\nAnger den databas som data ska laddas till. Standardvärdet är default.
Ignorerar fält och modeller som kan ha tagits bort sedan fixturen ursprungligen skapades.
\nAnger en enda app att leta efter fixturer i istället för att leta i alla appar.
\nAnger serialiseringsformat (t.ex. json eller xml) för fixturer läs från stdin.
Utesluter laddning av fixturerna från de angivna applikationerna och/eller modellerna (i form av app_label eller app_label.ModelName). Använd alternativet flera gånger för att utesluta mer än en app eller modell.
stdinLink to this heading#Du kan använda ett bindestreck som fixturnamn för att ladda inmatning från sys.stdin. Till exempel:
django-admin loaddata --format=json -\nVid läsning från stdin krävs alternativet --format för att ange serialiseringsformat för indata (t.ex. json eller xml).
Att ladda från stdin är användbart med omdirigeringar av standardinmatning och -utmatning. Till exempel:
django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -\nKommandot dumpdata kan användas för att generera indata för loaddata.
makemessagesLink to this heading#Går igenom hela källträdet i den aktuella katalogen och drar ut alla strängar som är markerade för översättning. Den skapar (eller uppdaterar) en meddelandefil i katalogen conf/locale (i Django-trädet) eller locale (för projekt och program). När du har gjort ändringar i meddelandefilerna måste du kompilera dem med compilemessages för användning med det inbyggda gettext-stödet. Se i18n documentation för mer information.
Det här kommandot kräver inga konfigurerade inställningar. Men när inställningarna inte är konfigurerade kan kommandot inte ignorera katalogerna MEDIA_ROOT och STATIC_ROOT eller inkludera LOCALE_PATHS.
Uppdaterar meddelandefilerna för alla tillgängliga språk.
\nAnger en lista med filändelser som ska undersökas (standard: html, txt, py eller js om --domain är djangojs).
Exempel på användning:
\ndjango-admin makemessages --locale=de --extension xhtml\nSeparera flera tillägg med kommatecken eller använd -e eller --extension flera gånger:
django-admin makemessages --locale=de --extension=html,txt --extension xml\nAnger den eller de locale(s) som ska bearbetas.
\nAnger den eller de lokala språkversioner som ska undantas från bearbetning. Om inget anges utesluts inga lokala språk.
\nExempel på användning:
\ndjango-admin makemessages --locale=pt_BR\ndjango-admin makemessages --locale=pt_BR --locale=fr\ndjango-admin makemessages -l pt_BR\ndjango-admin makemessages -l pt_BR -l fr\ndjango-admin makemessages --exclude=pt_BR\ndjango-admin makemessages --exclude=pt_BR --exclude=fr\ndjango-admin makemessages -x pt_BR\ndjango-admin makemessages -x pt_BR -x fr\nAnger domänen för meddelandefilerna. Alternativ som stöds är:
\ndjango för alla *.py, *.html och *.txt-filer (standard)
djangojs för *.js-filer
Följer symlinks till kataloger när du letar efter nya översättningssträngar.
\nExempel på användning:
\ndjango-admin makemessages --locale=de --symlinks\nIgnorerar filer eller kataloger som matchar det angivna glob-stilmönstret. Använd flera gånger för att ignorera fler.
Dessa mönster används som standard: 'CVS', '.*', '*~', '*.pyc'.
Exempel på användning:
\ndjango-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html\nInaktiverar standardvärdena för --ignore.
Avaktiverar uppdelning av långa meddelanderader i flera rader i språkfiler.
\nUndertrycker skrivning av ”#: filnamn:rad”-kommentarrader i språkfiler. Om du använder detta alternativ blir det svårare för tekniskt skickliga översättare att förstå varje meddelandes sammanhang.
Styr #: filnamn:rad kommentarrader i språkfiler. Om alternativet är:
full (standard om den inte anges): raderna innehåller både filnamn och radnummer.
file: radnumret utelämnas.
never: raderna undertrycks (samma som --no-location).
Kräver gettext 0.19 eller nyare.
Tar bort föråldrade meddelandesträngar från filerna .po.
Förhindrar att de temporära .pot-filerna som genereras innan .po-filen skapas raderas. Detta är användbart vid felsökning av fel som kan förhindra att de slutliga språkfilerna skapas.
makemigreringarLink to this heading#Skapar nya migreringar baserat på de ändringar som upptäcks i dina modeller. Migreringar, deras förhållande till appar med mera behandlas ingående i dokumentationen om migreringar.
\nOm du anger ett eller flera appnamn som argument begränsas de migreringar som skapas till den eller de angivna apparna och eventuella beroenden som behövs (t.ex. tabellen i andra änden av en ForeignKey).
Om du vill lägga till migreringar i en app som inte har en katalog med namnet migrations kör du makemigrations med appens app_label.
Undertrycker alla användarinstruktioner. Om en undertryckt fråga inte kan lösas automatiskt avslutas kommandot med felkod 3.
\nSkriver ut en tom migrering för de angivna apparna, för manuell redigering. Detta är för avancerade användare och bör inte användas om du inte är bekant med migreringsformatet, migreringsåtgärderna och beroendena mellan dina migreringar.
\nVisar vilka migreringar som skulle göras utan att några migreringsfiler faktiskt skrivs till disken. Om du använder detta alternativ tillsammans med --verbosity 3 visas även de fullständiga migreringsfiler som skulle skrivas.
Gör det möjligt att åtgärda migrationskonflikter.
\nTillåter namngivning av genererade migreringar istället för att använda ett genererat namn. Namnet måste vara en giltig Python identifierare.
\nGenerera migreringsfiler utan Django-version och tidsstämpelhuvud.
\nGör att makemigrations avslutas med en status som inte är noll när modelländringar utan migreringar upptäcks. Innebär --dry-run.
Omdirigerar loggutdata och inmatningsfrågor till stderr och skriver endast sökvägar för genererade migreringsfiler till stdout.
Sammanfogar modelländringar till den senaste migreringen och optimerar de resulterande operationerna.
\nDen uppdaterade migreringen kommer att ha ett genererat namn. För att bevara det tidigare namnet, ställ in det med --name.
migreraLink to this heading#Synkroniserar databastillståndet med den aktuella uppsättningen modeller och migreringar. Migreringar, deras förhållande till appar med mera behandlas ingående i dokumentationen om migreringar.
\nKommandot fungerar på olika sätt beroende på vilka argument som anges:
\nInga argument: Alla appar har alla sina migreringar körda.
<app_label>: Den angivna appen får sina migreringar körda, fram till den senaste migreringen. Detta kan innebära att andra appars migreringar också körs, på grund av beroenden.
<app_label> <migrationname>: För databasschemat till ett tillstånd där den namngivna migreringen tillämpas, men inga senare migreringar i samma app tillämpas. Detta kan innebära att migreringar inte tillämpas om du tidigare har migrerat förbi den namngivna migreringen. Du kan använda ett prefix för migreringsnamnet, t.ex. 0001, så länge det är unikt för det angivna appnamnet. Använd namnet zero för att migrera hela vägen tillbaka, dvs. för att återställa alla tillämpade migreringar för en app.
Anger den databas som ska migreras. Standardvärdet är default.
Markerar migreringarna upp till målet (enligt reglerna ovan) som tillämpade, men utan att faktiskt köra SQL för att ändra ditt databasschema.
\nDetta är avsett för avancerade användare som vill manipulera det aktuella migreringstillståndet direkt om de manuellt tillämpar ändringar; varnas för att användning av --fake riskerar att sätta migreringstillståndstabellen i ett tillstånd där manuell återställning kommer att krävas för att migreringarna ska fungera korrekt.
Tillåter Django att hoppa över en apps första migrering om alla databastabeller med namnen på alla modeller som skapats av alla CreateModel-operationer i den migreringen redan finns. Det här alternativet är avsett att användas när migreringar körs för första gången mot en databas som inte tidigare använde migreringar. Det här alternativet kontrollerar dock inte att databasschemat matchar utöver matchande tabellnamn och är därför bara säkert att använda om du är säker på att ditt befintliga schema matchar det som registreras i din första migrering.
Visar de migreringsåtgärder som kommer att utföras för det angivna kommandot migrate.
Gör det möjligt att skapa tabeller för appar utan migreringar. Även om detta inte rekommenderas är migreringsramverket ibland för långsamt i stora projekt med hundratals modeller.
\nUndertrycker alla användarinstruktioner. Ett exempel är en fråga om att ta bort inaktuella innehållstyper.
\nGör att migrate avslutas med en status som inte är noll när oanvända migreringar upptäcks.
Raderar icke-existerande migreringar från tabellen django_migrations. Detta är användbart när migreringsfiler som ersatts av en krossad migrering har tagits bort. Se Minska antalet migreringar för mer information.
optimera migreringenLink to this heading#Optimerar åtgärderna för den namngivna migreringen och åsidosätter den befintliga filen. Om migreringen innehåller funktioner som måste kopieras manuellt skapar kommandot en ny migreringsfil med suffixet _optimized som är avsedd att ersätta den namngivna migreringen.
Gör att optimizemigration avslutas med en status som inte är noll när en migrering kan optimeras.
runserverLink to this heading#Startar en lättviktig webbserver för utveckling på den lokala maskinen. Som standard körs servern på port 8000 på IP-adressen 127.0.0.1. Du kan ange en IP-adress och ett portnummer explicit.
Om du kör det här skriptet som en användare med normala privilegier (rekommenderas) kanske du inte har tillgång till att starta en port på ett lågt portnummer. Låga portnummer är reserverade för superanvändaren (root).
\nDen här servern använder det WSGI-applikationsobjekt som anges i inställningen WSGI_APPLICATION.
Utvecklingsservern laddar automatiskt om Python-koden för varje begäran, efter behov. Du behöver inte starta om servern för att kodändringar ska träda i kraft. Vissa åtgärder, som att lägga till filer, utlöser dock inte en omstart, så du måste starta om servern i dessa fall.
\nOm du använder Linux eller MacOS och installerar både pywatchman och Watchman-tjänsten, kommer kernelsignaler att användas för att autoladda servern (i stället för att polla tidsstämplar för filändringar varje sekund). Detta ger bättre prestanda i stora projekt, minskad svarstid efter kodändringar, mer robust ändringsdetektering och minskad energianvändning. Django stöder pywatchman 1.2.0 och högre.
När du startar servern, och varje gång du ändrar Python-kod medan servern körs, kommer ramverket för systemkontroll att kontrollera hela ditt Django-projekt för några vanliga fel (se kommandot check). Om några fel hittas kommer de att skrivas ut till standardutmatningen. Du kan använda alternativet --skip-checks för att hoppa över att köra systemkontroller.
Du kan köra så många samtidiga servrar som du vill, så länge de är på separata portar genom att köra django-admin runserver mer än en gång.
Observera att standard-IP-adressen, 127.0.0.1, inte är tillgänglig från andra maskiner i nätverket. Om du vill att utvecklingsservern ska kunna ses av andra datorer i nätverket använder du dess egen IP-adress (t.ex. 192.168.2.1), 0 (genväg för 0.0.0.0), 0.0.0.0 eller :: (med IPv6 aktiverat).
Du kan ange en IPv6-adress omgiven av parenteser (t.ex. [200a::1]:8000). Detta aktiverar automatiskt IPv6-stöd.
Ett värdnamn som endast innehåller ASCII-tecken kan också användas.
\nOm contrib-appen staticfiles är aktiverad (standard i nya projekt) kommer kommandot runserver att åsidosättas med sitt eget kommando runserver.
Loggning av varje begäran och svar från servern skickas till loggern django.server.
\nInaktiverar den automatiska omladdaren. Detta innebär att eventuella ändringar i Python-koden som du gör medan servern körs inte kommer att träda i kraft om de specifika Python-modulerna redan har laddats in i minnet.
\nInaktiverar användning av trådning i utvecklingsservern. Servern är flertrådig som standard.
\nAnvänder IPv6 för utvecklingsservern. Detta ändrar standard-IP-adressen från 127.0.0.1 till ::1.
Som standard skrivs en varning ut till konsolen om att runserver inte är lämplig för produktion:
WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.\nFor more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/\nStäll in denna miljövariabel på "true" för att dölja denna varning.
Port 8000 på IP-adress 127.0.0.1:
django-admin runserver\nPort 8000 på IP-adress 1.2.3.4:
django-admin runserver 1.2.3.4:8000\nPort 7000 på IP-adress 127.0.0.1:
django-admin runserver 7000\nPort 7000 på IP-adress 1.2.3.4:
django-admin runserver 1.2.3.4:7000\nPort 8000 på IPv6-adress ::1:
django-admin runserver -6\nPort 7000 på IPv6-adress ::1:
django-admin runserver -6 7000\nPort 7000 på IPv6-adressen 2001:0db8:1234:5678::9:
django-admin runserver [2001:0db8:1234:5678::9]:7000\nPort 8000 på IPv4-adressen för värden localhost:
django-admin runserver localhost:8000\nPort 8000 på IPv6-adressen för värden localhost:
django-admin runserver -6 localhost:8000\nSom standard serverar utvecklingsservern inte några statiska filer för din webbplats (t.ex. CSS-filer, bilder, saker under MEDIA_URL och så vidare). Om du vill konfigurera Django för att servera statiska media, läs Hur man hanterar statiska filer (t.ex. bilder, JavaScript, CSS).
Djangos kommando runserver tillhandahåller en WSGI-server. För att kunna köra under ASGI måste du använda en ASGI-server. Django Daphne-projektet tillhandahåller Integration med runserver som du kan använda.
sendtestemailLink to this heading#Skickar ett testmejl (för att bekräfta att det fungerar att skicka e-post via Django) till den eller de mottagare som anges. Till exempel:
\ndjango-admin sendtestemail foo@example.com bar@example.com\nDet finns ett par alternativ, och du kan använda vilken kombination som helst av dem tillsammans:
\nSkickar e-postmeddelanden till de e-postadresser som anges i MANAGERS med hjälp av mail_managers().
Skickar e-postmeddelanden till de e-postadresser som anges i ADMINS med hjälp av mail_admins().
shellLink to this heading#Startar den interaktiva Python-tolken.
\nAll models from installed apps are automatically imported into the shell\nenvironment. Models from apps listed earlier in INSTALLED_APPS take\nprecedence. The following common utilities are also imported:
from django.db import connection, reset_queries, models\nfrom django.conf import settings\nfrom django.utils import timezone\nFor a --verbosity of 2 or higher, the automatically imported objects will\nbe listed. To disable automatic importing entirely, use the --no-imports\nflag.
See the guide on customizing this behavior to add or remove automatic imports.
\n\n\nAnger vilket shell som ska användas. Som standard kommer Django att använda IPython eller bpython om något av dem är installerat. Om båda är installerade, ange vilket du vill ha så här:
\nIPython:
\ndjango-admin shell -i ipython\nbpython:
\ndjango-admin shell -i bpython\nOm du har ett ”rikt” skal installerat men vill tvinga fram användning av den ”vanliga” Python-tolken använder du python som gränssnittsnamn, så här:
django-admin shell -i python\nInaktiverar läsning av startskriptet för den ”vanliga” Python-tolken. Som standard läses det skript som pekas ut av miljövariabeln PYTHONSTARTUP eller skriptet ~/.pythonrc.py.
Avaktiverar automatisk import av modeller från INSTALLED_APPS.
Låter dig skicka ett kommando som en sträng för att exekvera det som Django, så här:
\ndjango-admin shell --command="import django; print(django.__version__)"\nDu kan också skicka in kod på standardinmatningen för att köra den. Till exempel:
\n$ django-admin shell <<EOF\n> import django\n> print(django.__version__)\n> EOF\nPå Windows matas REPL ut på grund av begränsningar i implementeringen av select.select() på den plattformen.
visa migreringarLink to this heading#Visar alla migreringar i ett projekt. Du kan välja ett av två format:
\nVisar alla appar som Django känner till, de migreringar som är tillgängliga för varje app och om varje migrering tillämpas eller inte (markerat med ett [X]` bredvid migreringsnamnet). För en ``--verbosity på 2 och högre visas även de tillämpade datatiderna.
Appar utan migreringar listas också, men har (inga migreringar) skrivet under sig.
Detta är standardutmatningsformatet.
\nVisar den migreringsplan som Django kommer att följa för att tillämpa migreringar. Liksom --list markeras tillämpade migreringar med en [X]. För en --verbosity på 2 och högre kommer alla beroenden av en migrering också att visas.
app_label argumenten begränsar utdata, men beroenden av tillhandahållna appar kan också inkluderas.
Anger vilken databas som ska undersökas. Standardvärdet är default.
sqlflushLink to this heading#Skriver ut de SQL-satser som skulle utföras för kommandot flush.
Anger den databas för vilken SQL ska skrivas ut. Standardvärdet är default.
sqlmigrateLink to this heading#Skriver ut SQL för den namngivna migreringen. Detta kräver en aktiv databasanslutning, som används för att lösa begränsningsnamn. Detta innebär att du måste generera SQL mot en kopia av den databas som du senare vill använda den på.
\nObservera att sqlmigrate inte färglägger sin utdata.
Genererar SQL för att ta bort tillämpningen av migreringen. Som standard skapas SQL för att köra migreringen i framåtriktad riktning.
\nAnger den databas för vilken SQL ska genereras. Standardvärdet är default.
sqlsequenceresetLink to this heading#Skriver ut SQL-satserna för återställning av sekvenser för det eller de angivna appnamnen.
\nSekvenser är index som används av vissa databasmotorer för att spåra nästa tillgängliga nummer för automatiskt inkrementerade fält.
\nAnvänd detta kommando för att generera SQL som åtgärdar fall där en sekvens inte är synkroniserad med sina automatiskt inkrementerade fältdata.
\nAnger den databas för vilken SQL ska skrivas ut. Standardvärdet är default.
kvashmigreringarLink to this heading#Pressar om möjligt ner migreringarna för app_label till och med migration_name till färre migreringar. De resulterande krossade migreringarna kan leva tillsammans med de okrossade på ett säkert sätt. För mer information, läs Minska antalet migreringar.
När start_migration_name anges kommer Django endast att inkludera migreringar som börjar från och med denna migrering. Detta hjälper till att mildra squashing-begränsningen av RunPython och django.db.migrations.operations.RunSQL migreringsoperationer.
Inaktiverar optimeraren när du genererar en krossad migrering. Som standard kommer Django att försöka optimera operationerna i dina migreringar för att minska storleken på den resulterande filen. Använd det här alternativet om den här processen misslyckas eller skapar felaktiga migreringar, men skicka också in en Django-buggrapport om beteendet, eftersom optimering är tänkt att vara säker.
\nUndertrycker alla användarinstruktioner.
\nStäller in namnet på den krossade migreringen. Om det utelämnas baseras namnet på den första och den sista migreringen, med _squashed_ däremellan.
Generera en komprimerad migreringsfil utan Django-version och tidsstämpelhuvud.
\nstartappLink to this heading#Skapar en Django-appkatalogstruktur för det angivna appnamnet i den aktuella katalogen eller den angivna destinationen.
\nSom standard innehåller den nya katalogen en fil models.py och andra appmallfiler. Om endast appnamnet anges kommer appkatalogen att skapas i den aktuella arbetskatalogen.
If the optional destination is provided, Django will use that name instead. If\nthe directory with the given name doesn’t exist, it will be created. You can\nuse ’.’ to denote the current working directory.
\n\nTill exempel:
\ndjango-admin startapp myapp /Users/jezdez/Code/myapp\nAnger sökvägen till en katalog med en anpassad appmallfil, eller en sökväg till ett okomprimerat arkiv (.tar) eller ett komprimerat arkiv (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip) som innehåller appmallfilerna.
Exempelvis skulle detta söka efter en appmall i den angivna katalogen när appen myapp skapas:
django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp\nDjango accepterar också webbadresser (http, https, ftp) till komprimerade arkiv med appmallfilerna och laddar ner och extraherar dem i farten.
Om du till exempel utnyttjar GitHubs funktion för att exponera repositories som zip-filer kan du använda en URL som:
\ndjango-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp\nAnger vilka filnamnstillägg i appmallen som ska återges med mallmotorn. Standardvärdet är py.
Anger vilka filer i appmallen (utöver de som matchar --extension) som ska återges med mallmotorn. Standardvärdet är en tom lista.
Anger vilka kataloger i appmallen som ska uteslutas, utöver .git och __pycache__. Om detta alternativ inte anges kommer kataloger som heter __pycache__ eller börjar med . att uteslutas.
Den template context som används för alla matchande filer är:
Alla alternativ som skickas till kommandot startapp (bland de alternativ som stöds av kommandot)
app_name – appens namn som skickas till kommandot
app_directory – den fullständiga sökvägen till den nyskapade appen
camel_case_app_name – appens namn i camel case-format
docs_version – version av dokumentationen: 'dev' eller '1.x'
django_version – versionen av Django, t.ex. '2.0.3'
starta projektLink to this heading#Skapar en Django-projektkatalogstruktur för det angivna projektnamnet i den aktuella katalogen eller den angivna destinationen.
\nSom standard innehåller den nya katalogen <django/conf/project_template>` manage.py och ett projektpaket (som innehåller en settings.py och andra filer).
Om endast projektnamnet anges kommer både projektkatalogen och projektpaketet att få namnet <projectname> och projektkatalogen kommer att skapas i den aktuella arbetskatalogen.
If the optional destination is provided, Django will use that name as the\nproject directory, and create manage.py and the project package within it.\nIf the directory with the given name doesn’t exist, it will be created. Use ’.’\nto denote the current working directory.
Till exempel:
\ndjango-admin startproject myproject /Users/jezdez/Code/myproject_repo\nAnger en katalog, filväg eller URL för en anpassad projektmall. Se dokumentationen för startapp --template för exempel och användning. Samma säkerhetsöverväganden som beskrivs för startapp-mallar gäller även här: skadliga eller dåligt konstruerade mallar kan medföra svagheter eller förbruka överdrivna resurser, och mallar bör granskas noggrant före användning.
Anger vilka filnamnstillägg i projektmallen som ska återges med mallmotorn. Standardvärdet är py.
Anger vilka filer i projektmallen (utöver de som matchar --extension) som ska återges med mallmotorn. Standardvärdet är en tom lista.
Anger vilka kataloger i projektmallen som ska uteslutas, utöver .git och __pycache__. Om det här alternativet inte anges kommer kataloger som heter __pycache__ eller börjar med . att uteslutas.
Den template context som används är:
Alla alternativ som skickas till kommandot startproject (bland de alternativ som stöds av kommandot)
project_name – projektnamnet som skickas till kommandot
project_directory – den fullständiga sökvägen till det nyskapade projektet
secret_key – en slumpmässig nyckel för inställningen :setting:`SECRET_KEY
docs_version – version av dokumentationen: 'dev' eller '1.x'
django_version – versionen av Django, t.ex. '2.0.3'
Se även rendering warning och trusted code warning som nämns för startapp.
testLink to this heading#Kör tester för alla installerade appar. Se Testning i Django för mer information.
\nStoppar testkörningen och rapporterar felet omedelbart efter att ett test misslyckats.
\nStyr den testkörningsklass som används för att köra tester. Detta värde åsidosätter det värde som anges av inställningen TEST_RUNNER.
Undertrycker alla uppmaningar till användaren. En typisk uppmaning är en varning om att ta bort en befintlig testdatabas.
\nKommandot test tar emot alternativ på uppdrag av det angivna --testrunner. Detta är alternativen för standardtestlöparen: DiscoverRunner.
Bevarar testdatabasen mellan testkörningar. Fördelen med detta är att man hoppar över både skapande och förstörande åtgärder, vilket kan minska tiden för testkörning avsevärt, särskilt i en stor testsvit. Om testdatabasen inte finns kommer den att skapas vid den första körningen och sedan bevaras för varje efterföljande körning. Om inte testinställningen MIGRATE är False, kommer alla oanvända migreringar också att tillämpas på testdatabasen innan testsviten körs.
Slumpar ordningen på testerna innan de körs. Detta kan hjälpa till att upptäcka tester som inte är ordentligt isolerade. Den testordning som genereras av detta alternativ är en deterministisk funktion av det heltal som anges. Om inget seed anges väljs ett seed slumpmässigt och skrivs ut på konsolen. För att upprepa en viss testordning, skicka ett frö. Testordningarna som genereras av detta alternativ bevarar Djangos garantier för testordning. De håller också tester grupperade efter testfallsklass.
\nDe blandade ordningarna har också en speciell konsistensegenskap som är användbar när man begränsar isoleringsfrågor. För ett givet frö och när en delmängd av testerna körs kommer den nya ordningen att vara den ursprungliga blandningen begränsad till den mindre uppsättningen. På samma sätt kommer ordningen på de ursprungliga testerna att vara densamma i den nya ordningen när du lägger till tester samtidigt som fröet förblir detsamma.
\nSorterar testfall i motsatt exekveringsordning. Detta kan hjälpa till vid felsökning av bieffekter av tester som inte är ordentligt isolerade. Gruppering efter testklass bevaras när detta alternativ används. Detta kan användas tillsammans med --shuffle för att vända ordningen för ett visst frö.
Sätter inställningen DEBUG till True innan tester körs. Detta kan hjälpa till att felsöka testfel.
Aktiverar SQL logging för misslyckade tester. Om --verbosity är 2, kommer frågor i godkända tester också att matas ut.
Kör tester i separata parallella processer. Eftersom moderna processorer har flera kärnor gör detta att testerna kan köras betydligt snabbare.
\nUsing --parallel without a value, or with the value auto, runs one test\nprocess per core according to multiprocessing.cpu_count(). You can\noverride this by passing the desired number of processes, e.g.\n--parallel 4, or by setting the DJANGO_TEST_PROCESSES environment\nvariable.
Django distribuerar testfall - unittest.TestCase subclasses - till subprocesser. Om det finns färre testfallsklasser än konfigurerade processer, kommer Django att minska antalet processer i enlighet med detta.
Varje process får sin egen databas. Du måste se till att olika testfallsklasser inte får tillgång till samma resurser. Exempelvis bör testfallsklasser som använder filsystemet skapa en temporär katalog för eget bruk.
\n\nDetta alternativ kräver tredjeparts tblib-paketet för att visa spårningar korrekt:
$ python -m pip install tblib\nDen här funktionen är inte tillgänglig i Windows. Den fungerar inte heller med Oracle-databasens backend.
\nOm du vill använda pdb när du felsöker tester måste du inaktivera parallellkörning (--parallel=1). Du kommer att se något i stil med bdb.BdbQuit om du inte gör det.
Kör endast tester märkta med de angivna taggarna. Kan anges flera gånger och kombineras med test --exclude-tag.
Tester som inte laddas betraktas alltid som matchande.
\nUtesluter tester märkta med de angivna taggarna. Kan anges flera gånger och kombineras med test --tag.
Kör testmetoder och klasser som matchar testnamnsmönster, på samma sätt som unittests -k-alternativ. Kan anges flera gånger.
Startar en pdb-felsökare vid varje fel eller misslyckande i testet. Om du har det installerat används ipdb istället.
Slänger utdata (stdout och stderr) för godkända tester, på samma sätt som unittests alternativ --buffer.
Django automatically calls faulthandler.enable() when starting the\ntests, which allows it to print a traceback if the interpreter crashes. Pass\n--no-faulthandler to disable this behavior.
Utmatning av tidsangivelser, inklusive databasinstallation och total körtid.
\nVisar de N långsammaste testfallen (N=0 för alla).
\ntestserverLink to this heading#Kör en Django-utvecklingsserver (som i runserver) med data från den eller de angivna fixturerna.
Till exempel: detta kommando:
\ndjango-admin testserver mydata.json\n…skulle utföra följande steg:
\nSkapa en testdatabas, enligt beskrivningen i testdatabasen.
Fyller på testdatabasen med fixturdata från de angivna fixturerna. (För mer information om fixturer, se dokumentationen för loaddata ovan)
Kör Django-utvecklingsservern (som i runserver), riktad mot denna nyskapade testdatabas i stället för din produktionsdatabas.
Detta är användbart på flera olika sätt:
\nNär du skriver enhetstester av hur dina vyer fungerar med vissa fixturdata, kan du använda testserver för att interagera med vyerna i en webbläsare, manuellt.
Let’s say you’re developing your Django application and have a ”pristine”\ncopy of a database that you’d like to interact with. You can dump your\ndatabase to a fixture (using the\ndumpdata command, explained above), then use testserver to run\nyour web application with that data. With this arrangement, you have the\nflexibility of messing up your data in any way, knowing that whatever data\nchanges you’re making are only being made to a test database.
Observera att den här servern inte automatiskt upptäcker ändringar i din Python-källkod (som runserver gör). Den upptäcker dock ändringar i mallar.
Anger en annan port, eller IP-adress och port, än standardvärdet 127.0.0.1:8000. Detta värde följer exakt samma format och har exakt samma funktion som argumentet till kommandot runserver.
Exempel:
\nFör att köra testservern på port 7000 med fixture1 och fixture2:
django-admin testserver --addrport 7000 fixture1 fixture2\ndjango-admin testserver fixture1 fixture2 --addrport 7000\n(Ovanstående uttalanden är likvärdiga. Vi tar med båda för att visa att det inte spelar någon roll om alternativen kommer före eller efter fixturargumenten)
\nFör att köra på 1.2.3.4:7000 med en test fixtur:
django-admin testserver --addrport 1.2.3.4:7000 test\nUndertrycker alla uppmaningar till användaren. En typisk uppmaning är en varning om att ta bort en befintlig testdatabas.
\nVissa kommandon är endast tillgängliga när applikationen django.contrib som implementerar dem har aktiverats. Detta avsnitt beskriver dem grupperade efter deras applikation.
django.contrib.authLink to this heading#byt lösenordLink to this heading#Detta kommando är endast tillgängligt om Djangos autentiseringssystem (django.contrib.auth) är installerat.
Gör det möjligt att ändra en användares lösenord. Du uppmanas att ange ett nytt lösenord två gånger för den aktuella användaren. Om inmatningarna är identiska blir detta omedelbart det nya lösenordet. Om du inte anger någon användare kommer kommandot att försöka ändra lösenordet för den användare vars användarnamn matchar den aktuella användaren.
\nAnger vilken databas som ska användas för att söka efter användaren. Standardvärdet är default.
Exempel på användning:
\ndjango-admin changepassword ringo\nskapa superanvändareLink to this heading#Detta kommando är endast tillgängligt om Djangos autentiseringssystem (django.contrib.auth) är installerat.
Skapar ett superanvändarkonto (en användare som har alla behörigheter). Detta är användbart om du behöver skapa ett första superanvändarkonto eller om du behöver generera superanvändarkonton för dina webbplatser på ett programmatiskt sätt.
\nNär kommandot körs interaktivt kommer det att fråga efter ett lösenord för det nya superanvändarkontot. När kommandot körs icke-interaktivt kan du ange ett lösenord genom att ange miljövariabeln DJANGO_SUPERUSER_PASSWORD. Annars anges inget lösenord och superanvändarkontot kan inte logga in förrän ett lösenord har angetts manuellt för det.
I icke-interaktivt läge faller USERNAME_FIELD och obligatoriska fält (listade i REQUIRED_FIELDS) tillbaka till miljövariablerna DJANGO_SUPERUSER_<uppercase_field_name>, såvida de inte åsidosätts av ett kommandoradsargument. Om du t.ex. vill tillhandahålla ett fält för e-post kan du använda miljövariabeln DJANGO_SUPERUSER_EMAIL.
Undertrycker alla användarinstruktioner. Om en undertryckt fråga inte kan lösas automatiskt avslutas kommandot med felkod 1.
\nAnvändarnamnet och e-postadressen för det nya kontot kan anges med argumenten --username och --email på kommandoraden. Om något av dessa inte anges kommer createsuperuser att fråga efter det när det körs interaktivt.
Anger den databas i vilken superuser-objektet ska sparas.
\nDu kan underklassa management-kommandot och åsidosätta get_input_data() om du vill anpassa datainmatning och validering. I källkoden finns mer information om den befintliga implementeringen och metodens parametrar. Det kan till exempel vara användbart om du har en ForeignKey i REQUIRED_FIELDS och vill tillåta att en instans skapas istället för att ange primärnyckeln för en befintlig instans.
django.contrib.contenttypesLink to this heading#ta bort_stale_innehållstyperLink to this heading#Detta kommando är endast tillgängligt om Djangos contenttypes app (django.contrib.contenttypes) är installerat.
Raderar inaktuella innehållstyper (från borttagna modeller) i din databas. Alla objekt som är beroende av de borttagna innehållstyperna kommer också att raderas. En lista över borttagna objekt visas innan du bekräftar att det är okej att fortsätta med borttagningen.
\nAnger vilken databas som ska användas. Standardvärdet är default.
Raderar inaktuella innehållstyper, inklusive innehåll från tidigare installerade appar som har tagits bort från INSTALLED_APPS. Standardvärde är False.
django.contrib.gisLink to this heading#ogrinspectLink to this heading#Detta kommando är endast tillgängligt om GeoDjango (django.contrib.gis) är installerat.
Se dess description i GeoDjango-dokumentationen.
django.contrib.sessionsLink to this heading#clearsessionsLink to this heading#Kan köras som ett cron-jobb eller direkt för att rensa bort utgångna sessioner.
\ndjango.contrib.staticfilesLink to this heading#samla statisktLink to this heading#Detta kommando är endast tillgängligt om applikationen för statiska filer (django.contrib.staticfiles) är installerad.
Se dess description i staticfiles dokumentation.
findstaticLink to this heading#Detta kommando är endast tillgängligt om applikationen för statiska filer (django.contrib.staticfiles) är installerad.
Se dess description i staticfiles dokumentation.
Även om vissa kommandon kan tillåta egna anpassade alternativ, tillåter alla kommandon följande alternativ som standard:
\nAdds the given filesystem path to the Python sys.path module\nattribute. If this isn’t provided, django-admin will use the\nPYTHONPATH environment variable.
Detta alternativ är onödigt i manage.py, eftersom det tar hand om att ställa in Python-sökvägen åt dig.
Exempel på användning:
\ndjango-admin migrate --pythonpath='/home/djangoprojects/myproject'\nAnger vilken inställningsmodul som ska användas. Inställningsmodulen bör vara i Python-paketsyntax, t.ex. mysite.settings. Om detta inte anges kommer django-admin att använda miljövariabeln DJANGO_SETTINGS_MODULE.
Detta alternativ är onödigt i manage.py, eftersom det använder settings.py från det aktuella projektet som standard.
Exempel på användning:
\ndjango-admin migrate --settings=mysite.settings\nVisar en fullständig stackspårning när ett CommandError uppstår. Som standard kommer django-admin att visa ett felmeddelande när ett CommandError inträffar och en fullständig stack trace för alla andra undantag.
Detta alternativ ignoreras av runserver.
Exempel på användning:
\ndjango-admin migrate --traceback\nAnger hur mycket meddelande- och felsökningsinformation som ett kommando ska skriva ut till konsolen.
\n0 betyder ingen utmatning.
1 betyder normal utmatning (standard).
2 betyder utförlig utdata.
3 betyder mycket utförlig utdata.
Detta alternativ ignoreras av runserver.
Exempel på användning:
\ndjango-admin migrate --verbosity 2\nDisables colorized command output. Some commands format their output to be\ncolorized. For example, errors will be printed to the console in red and SQL\nstatements will be syntax highlighted.
\nExempel på användning:
\ndjango-admin runserver --no-color\nTvingar fram färgläggning av kommandoutmatningen om den annars skulle vara inaktiverad, vilket diskuteras i Syntax färgläggning. Du kanske t.ex. vill skicka färgade utdata till ett annat kommando.
\nHoppar över att köra systemkontroller innan kommandot körs. Detta alternativ är endast tillgängligt om requires_system_checks inte är en tom lista eller tupel.
Exempel på användning:
\ndjango-admin migrate --skip-checks\nKommandona django-admin / manage.py kommer att använda vackra färgkodade utdata om din terminal stöder ANSI-färgade utdata. Det kommer inte att använda färgkoderna om du skickar kommandots utdata till ett annat program om inte alternativet --force-color används.
I Windows 10 tillåter programmet Windows Terminal, VS Code och PowerShell (där bearbetning i virtuell terminal är aktiverad) färgad utdata och stöds som standard.
\nUnder Windows stöder inte den gamla inbyggda konsolen cmd.exe ANSI escape-sekvenser, så som standard finns det ingen färgutmatning. I detta fall behövs något av de två tredjepartsbiblioteken:
Installera colorama, ett Python-paket som översätter ANSI-färgkoder till Windows API-anrop. Django-kommandon kommer att upptäcka dess närvaro och använda dess tjänster för att färglägga utdata precis som på Unix-baserade plattformar. colorama kan installeras via pip:
...\\> py -m pip install "colorama >= 0.4.6"\nInstallera ANSICON, ett tredjepartsverktyg som gör det möjligt för cmd.exe att bearbeta ANSI-färgkoder. Django-kommandon kommer att upptäcka dess närvaro och använda dess tjänster för att färglägga utdata precis som på Unix-baserade plattformar.
Andra moderna terminalmiljöer på Windows, som stöder terminalfärger, men som inte automatiskt upptäcks som stödda av Django, kan ”fejka” installationen av ANSICON genom att ställa in lämplig miljövariabel, ANSICON="on".
De färger som används för syntaxmarkering kan anpassas. Django levereras med tre färgpaletter:
\ndark, lämplig för terminaler som visar vit text på svart bakgrund. Detta är standardpaletten.
light, lämpar sig för terminaler som visar svart text på vit bakgrund.
nocolor, som inaktiverar syntaxmarkering.
Du väljer en palett genom att ange en DJANGO_COLORS-miljövariabel som anger vilken palett du vill använda. Om du till exempel vill ange paletten light i ett Unix- eller OS/X BASH-skal, kör du följande vid kommandotolken:
export DJANGO_COLORS="light"\nDu kan också anpassa de färger som används. Django specificerar ett antal roller där färg används:
\nerror - Ett allvarligt fel.
notice - Ett mindre fel.
uccess - En framgång.
warning - En varning.
sql_field - Namnet på ett modellfält i SQL.
sql_coltype - Typen av ett modellfält i SQL.
sql_keyword - Ett SQL-nyckelord.
sql_table - Namnet på en modell i SQL.
http_info - Ett 1XX HTTP-informationssvar från servern.
http_success - Ett 2XX HTTP Success-serversvar.
http_not_modified - Ett 304 HTTP Not Modified-serversvar.
http_redirect - Ett 3XX HTTP Redirect-serversvar annat än 304.
http_not_found - Ett 404 HTTP Not Found-serversvar.
http_bad_request - Ett 4XX HTTP Bad Request-serversvar annat än 404.
http_server_error - Ett 5XX HTTP Server Error-svar.
migrate_heading - En rubrik i ett kommando för migrationshantering.
migrate_label - Ett namn på migreringen.
Var och en av dessa roller kan tilldelas en specifik förgrunds- och bakgrundsfärg från följande lista:
\nsvart
”röd
grön
gult
blått
magenta
cyan
vit
Var och en av dessa färger kan sedan ändras med hjälp av följande visningsalternativ:
\nfett
underscore
blink
omvänd
”dölja
En färgspecifikation följer något av följande mönster:
\nrole=fg
role=fg/bg
roll=fg,option,option
roll=fg/bg,option,option
där role är namnet på en giltig färgroll, fg är förgrundsfärgen, bg är bakgrundsfärgen och varje option är ett av färgmodifieringsalternativen. Flera färgspecifikationer separeras sedan med ett semikolon. Till exempel:
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"\nskulle ange att fel visas med blinkande gult på blått och meddelanden visas med magenta. Alla andra färgroller skulle lämnas ofärgade.
\nFärger kan också specificeras genom att utöka en baspalett. Om du anger ett palettnamn i en färgspecifikation laddas alla färger som impliceras av den paletten. Så här gör du:
\nexport DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"\nskulle ange användningen av alla färger i den ljusa färgpaletten, utom färgerna för fel och meddelanden som skulle åsidosättas enligt specifikationen.
\nOm du använder Bash-skalet, överväg att installera Django bash-kompletteringsscriptet, som finns i extras/django_bash_completion i Django-källdistributionen. Det möjliggör tabkomplettering av kommandon i django-admin och manage.py, så att du till exempel kan …
Typ django-admin.
Tryck på [TAB] för att se alla tillgängliga alternativ.
Skriv sql och sedan [TAB] för att se alla tillgängliga alternativ vars namn börjar med sql.
Se Hur man skapar egna kommandon för django-admin för information om hur du lägger till anpassade åtgärder.
\nPython-filerna som skapas av startproject, startapp, optimizemigration, makemigrations och squashmigrations formateras med kommandot black om det finns i din PATH.
Om du har black globalt installerat, men inte vill att det ska användas för det aktuella projektet, kan du ange PATH explicit:
PATH=path/to/venv/bin django-admin makemigrations\nFör kommandon som använder stdout kan du vid behov skicka utdata till black:
django-admin inspectdb | black -\nOm du vill anropa ett managementkommando från kod använder du call_command().
namnnamnet på kommandot som ska anropas eller ett kommando-objekt. Att skicka namnet är att föredra om inte objektet krävs för testning.
\n*argsen lista med argument som accepteras av kommandot. Argumenten skickas till argumentparsern, så att du kan använda samma stil som på kommandoraden. Till exempel:, call_command('flush', '--verbosity=0').
**alternativnamngivna alternativ som accepteras på kommandoraden. Alternativen skickas till kommandot utan att argumentparsern aktiveras, vilket innebär att du måste skicka rätt typ. Till exempel:, call_command('flush', verbosity=0) (noll måste vara ett heltal snarare än en sträng).
Exempel:
\nfrom django.core import management\nfrom django.core.management.commands import loaddata\n\nmanagement.call_command("flush", verbosity=0, interactive=False)\nmanagement.call_command("loaddata", "test_data", verbosity=0)\nmanagement.call_command(loaddata.Command(), "test_data", verbosity=0)\nObservera att kommandoval som inte tar några argument skickas som nyckelord med True eller False, som du kan se med alternativet interactive ovan.
Namngivna argument kan skickas genom att använda någon av följande syntaxer:
\n# Similar to the command line\nmanagement.call_command("dumpdata", "--natural-foreign")\n\n# Named argument similar to the command line minus the initial dashes and\n# with internal dashes replaced by underscores\nmanagement.call_command("dumpdata", natural_foreign=True)\n\n# `use_natural_foreign_keys` is the option destination variable\nmanagement.call_command("dumpdata", use_natural_foreign_keys=True)\nVissa kommandoalternativ har olika namn när du använder call_command() istället för django-admin eller manage.py. Till exempel: översätts django-admin createsuperuser --no-input till call_command('createsuperuser', interactive=False). För att hitta vilket nyckelordsargumentnamn som ska användas för call_command(), kontrollera kommandots källkod för dest-argumentet som skickas till parser.add_argument().
Kommandoval som innehåller flera alternativ skickas till en lista:
\nmanagement.call_command("dumpdata", exclude=["contenttypes", "auth"])\nReturvärdet för funktionen call_command() är detsamma som returvärdet för kommandots metod handle().
Observera att du kan omdirigera standardutdata- och felströmmar eftersom alla kommandon stöder alternativen stdout och stderr. Du kan till exempel skriva:
with open("/path/to/command_output", "w") as f:\n management.call_command("dumpdata", stdout=f)\n