Hvordan pakke Python-apper med BeeWare koffert

Python kommer til kort i noen få områder. For eksempel er Python ikke det raskeste språket, men tredjepartsbiblioteker som NumPy lar deg omgå det. Hvor Python er mest mangelfull, er emballasje. Det vil si at Python mangler en konsekvent intern mekanisme for å generere en frittstående binær fra et program. Gå og Rust gjør dette. Hvorfor kan ikke Python?

Det kommer for det meste ned på at Python ikke har en kultur av slike brukstilfeller før relativt nylig i sin historie. Og så, nylig begynte tredjepartsmoduler å vises som gjør at Python-apper kan pakkes som frittstående binærfiler. PyInstaller - som jeg dekket tidligere - er en slik app. I denne artikkelen ser vi på et enda mer elegant og kraftig verktøy for Python-app-emballasje, BeeWare's Briefcase.

[Også på: Python virtualenv og venv do's and don'ts]

Imidlertid er det to forbehold som er verdt å påpeke om kofferten. For det første gjør ikke koffert emballasje på tvers av plattformer; du trenger å bygge på plattformen du distribuerer for. For det andre fungerer koffert best med apper som bruker et GUI-verktøysett av noe slag. Vi vil gå nærmere inn på disse problemene nedenfor.

Hva er BeeWare koffert?

Koffert er en del av en generell pakke med verktøy fra BeeWare for å lage apper, med de forskjellige delene som utfyller hverandre. For eksempel lar BeeWare's Kivy deg lage plattform-GUI-apper i Python som kjører ikke bare på alle de store OS-plattformene, men også på nettet. Men her vil vi fokusere på kofferten, som kan brukes med eller uten de andre verktøyene.

Koffertpakken pakker apper for alle operativsystemene den støtter ved hjelp av et vanlig format for apper på den plattformen:

Microsoft Windows (MSI-installasjonsprogram)
Mac os (.app formatfil)
Linux (AppImage)
iOS (Xcode-prosjekt)
Android (Gradle-prosjekt)

For å distribuere på iOS eller Android, trenger du utviklingssett for disse plattformene.

En ting koffert gjørikke støtte er distribusjon på tvers av plattformer. For eksempel, hvis du er en Windows-bruker, kan du ikke bygge en macOS-app; du trenger macOS for å gjøre det. Andre app-bundlere for Python er tilsvarende begrenset, så denne begrensningen er på ingen måte eksklusiv for koffert.

Dokumentmappen er heller ikke en "kompilator" - den forvandler ikke Python-programmer til deres opprinnelige maskinkodeekvivalenter. Appene dine kjører ikke raskere når de distribueres som koffertapper enn de vanligvis gjør.

Prosjektoppsett for koffert

Koffert krever at du setter opp en dedikert prosjektkatalog med sitt eget virtuelle miljø. Hvis du ikke er kjent med "venvs" ennå, som Python-virtuelle miljøer kalles, er det verdt å få fart på dem, ettersom toppmoderne Python-utvikling dreier seg tungt om dem.

Etter at du har satt opp en venv ogpip-koffert inn i den, vil du bruke koffertens eget kommandolinjeverktøy for å sette opp, administrere og levere koffertpakkerte prosjekter. Dette ligner på hvordan verktøy som poesi fungerer: De fleste av dine interaksjoner på høyt nivå med prosjektet er gjennom verktøyet, slik at du ikke trenger å lage filer manuelt eller redigere konfigurasjoner.

For å starte et nytt koffertprosjekt, åpne CLI i prosjektkatalogen din, aktiver det virtuelle miljøet (forutsatt at du ikke bruker en IDEs CLI til å gjøre det automatisk), og skrivkoffert ny. Dette skaper stillas i prosjektkatalogen for et koffertprosjekt.

Du må svare på noen spørsmål om prosjektet først, og for de fleste av dem kan du bare trykkeTast inn for å godta standard. Men ett av spørsmålene du vil bli stilt - det siste, faktisk - har stor betydning: valget av GUI-rammeverk som skal brukes.

Et av BeeWares andre tilbud er en UI-verktøysett som heter Toga, for å lage GUIer i Python-programmer ved hjelp av plattform-native UI-komponenter. Hvis du vil hoppe inn i å lære Toga mens du også jobber med koffert, er det ingenting som hindrer deg. Eller du kan velge "Ingen" og opprette en "hodeløs" app som kjører fra kommandolinjen, eller du kan bruke et tredjeparts UI-verktøysett eller et vindussystem som Pyglet eller PyQT.

Vær oppmerksom på at hvis du ikke installerer noe brukergrensesnittverktøy, vil appen ikke ha konsollinteraktivitet overhodet - dvs. det vil ikke åpne et konsollvindu og det vil ikke skrive ut noe til konsollen. Dette er nyttig hvis du distribuerer et program som ikke krever konsollinteraksjon - for eksempel hvis det kjører som en lokal webserver og bruker en nettleser for interaksjon. Men det er foreløpig ikke noe alternativ å la koffertprogrammer uten UI-pakke installert kjøre med en konsoll.

Dokumentmappe prosjektstruktur

En nystartet koffertapp-katalog kommer med flere forhåndsinstallerte filer:

Det øverste nivået i appkatalogen inneholder prosjektlisensen,pyproject.toml fil, en prøve README-fil i ReStructured Text-format, og en.gitignore fil som kommer forhåndstilpasset med vanlige kataloger for å utelate fra ethvert Git-arkiv opprettet for prosjektet.
Desrc katalogen inneholder kildekoden til appen din, med to underkataloger: en som inneholder appen (den har samme navn som prosjektkatalogen din) og en som inneholder appens metadata.
Appkatalogen inneholder enressurser katalog, som brukes til å lagre ressurser som applikasjonsikoner.

Koffertprosjektkommandoer

Destresskoffert kommando er hvordan du utfører de fleste av dine interaksjoner med et koffertprosjekt. Vi dekketny kommandoen ovenfor, som brukes til å sette opp et koffertprosjekt i en gitt mappe. Men du må vanligvis bruke mange andre kommandoer i løpet av livssyklusen til en koffertapp, og noen av dem kan være litt motstridende.

Her er de vanligste koffertkommandoene du bruker:

dev: Når du befinner deg i en appkatalog, kjører denne kommandoen den appendev-modus. Dev-modus lar deg kjøre applikasjonen med det komplette utvalget av installerte biblioteker, men uten å måtte være formelt pakket for levering. Når du utvikler applikasjonen din, vil du mest kjøre den med dev-modus. Hvis noen avhengigheter har endret seg siden forrige gang du løpdev, bruke-d flagg for å oppdatere dem.
bygge: Bygger en kopi av applikasjonen i skjemaet som trengs for å pakke den for distribusjon. Dette skiller seg fradev ved at du kan bygge for forskjellige plattformer hvis stillaset er installert.
Oppdater: Oppdaterer en applikasjonsbygging. Dette er den raske måten å sørge for at applikasjonen din har den nyeste koden, i stedet for å brukebygge, som regenererer mange flere filer. Send meg-d flagg for å oppdatere avhengigheter, og-r flagg for å oppdatere ressurser (det vil si å kopiere ressurser fra dev-versjonen av appen din til build-versjonen).
løpe: Kjører den innebygde versjonen av appen. Dette simulerer i hovedsak å kjøre den pakkede og distribuerte versjonen av applikasjonen. Send meg-u flagg for å oppdatere hvilken som helst kode før du kjører.
pakke: Oppretter en applikasjonsinstallasjonspakke fra den innebygde versjonen av appen. Sluttresultatet av dette er en gjenstand du kan gi andre til å installere programmet ditt - f.eks. En .MSI på Windows.

Her er noen av de mindre brukte koffertkommandoene:

skape: Ikke forveksles medny, skape skaper stillaset for en applikasjonsinstallatør - en måte å bygge appens installasjonsprogram for en bestemt plattform. Når du setter opp en app medny, det kommer med stillas for plattformen du jobber med;skape lar deg legge til stillas for en annen plattform om nødvendig.
Oppgradering: Oppgraderer komponentene som brukes til å pakke appen, for eksempel Wix-rammeverket.
publisere: Publiserer den pakkede appen til en publikasjonskanal, for eksempel en appbutikk. (I skrivende stund fungerer denne funksjonen ikke ennå.)

For å oppsummere er dette rekkefølgen du vil bruke koffertkommandoene i den typiske app-livssyklusen:

ny for å lage appen
dev å kjøre appen mens du jobber med den
bygge for å lage en versjon av appen som skal pakkes for distribusjon
løpe for å teste-kjøre den pakkede versjonen av appen
Oppdater for å holde den pakkede versjonen av appen oppdatert med kodeendringer
pakke for å distribuere den pakkede versjonen av appen med et installasjonsprogram

Opprettelse av koffertapp

Å lage et Python-program som en koffertapp er mye det samme som å lage en hvilken som helst annen Python-app. Hovedproblemene er prosjektstrukturen. Appens inngangspunkt er__main__.py i appkatalogen, som lastes innapp.py fra samme katalog og kjøreshoved(). Når du initialiserer et prosjekt, fylles det med plassholderversjoner av noen prosjektfiler, som du kan bygge ut eller erstatte etter behov.

Hvis du forvandler eneksisterende prosjekt for å bruke koffert, sørg for at du strukturerer det på en slik måte at inngangspunktet er det kofferten forventer. For eksempel hvis du ikke lagret koden i ensrc katalogen, må du flytte koden tilsrc og fikse eventuelle inkompatibiliteter i banene og katalogstrukturene.

Den andre tingen å huske på er hvordan du håndterer avhengighet fra tredjepart. Depyproject.toml filen i prosjektkatalogen kontrollerer hvilke avhengigheter du vil legge til i prosjektet. Hvis prosjektet ditt hetermitt prosjekt, deretterpyproject.toml vil inneholde en seksjon som heter[tool.briefcase.app.myproject], med enkrever linje som viser hvert krav slik de ville være spesifisert i akrav.txt fil. Hvis prosjektet ditt for eksempel trengerregex ogsvart, ville du satt den linjen tilkrever = ["regex", "svart"]. Du vil da brukekoffert dev -d å oppdatere avhengighetene for utviklingsversjonen av prosjektet, ogkoffertoppdatering -d for å oppdatere avhengigheter i den pakkede versjonen.

Koffertapp emballasje og levering

Når du har løptkoffertpakke, vil du se en omfordeling av programmet ditt vises i en underkatalog til prosjektkatalogen som tilsvarer plattformen du bygget for. For Microsoft Windows, for eksempel, vil katalogen værevinduer, og den omfordelbare vil være en.msi fil med samme navn som prosjektet ditt. For Android og iOS vil resultatene være prosjekter for henholdsvis Gradle og Xcode, og disse må kompileres ved hjelp av disse verktøyene for å kunne distribueres til disse plattformene.