Tutorial 7 - Die (Dritt)-Partei in Gang bringen

Bisher haben wir in der von uns erstellten Anwendung nur unseren eigenen Code sowie den von BeeWare bereitgestellten Code verwendet. In einer realen Anwendung werden Sie jedoch wahrscheinlich eine Bibliothek eines Drittanbieters verwenden wollen, die Sie aus dem Python Package Index (PyPI) herunterladen.

Ändern wir unsere Anwendung so, dass sie eine Bibliothek eines Drittanbieters enthält.

Adding a package

Let’s modify our application to say a little bit more than just „Hi, there!“.

To generate some more interesting text for the dialog, we’re going to use a library called Faker . Faker is a Python package that generates fake content, including names and text blocks. The names and words in the text block are generated from an arbitrary list of words provided by Faker. We’re going to use Faker to construct a fake message, as if someone is responding to the user.

Fügen wir einen httpx-API-Aufruf zu unserer Anwendung hinzu. Fügen Sie einen Import am Anfang der app.py hinzu, um httpx zu importieren:

import faker

Dann modifizieren Sie den say_hello() Callback so, dass er wie folgt aussieht:

async def say_hello(self, widget):
    fake = faker.Faker()
    await self.main_window.dialog(
        toga.InfoDialog(
            greeting(self.name_input.value),
            f"A message from {fake.name()}: {fake.text()}",
        )
    )

Führen wir unsere aktualisierte Anwendung im Briefcase-Entwicklermodus aus, um zu prüfen, ob unsere Änderung funktioniert.

macOSLinuxWindowsAndroidiOS

(beeware-venv) $ briefcase dev
Traceback (most recent call last):
File ".../venv/bin/briefcase", line 5, in <module>
    from briefcase.__main__ import main
File ".../venv/lib/python3.13/site-packages/briefcase/__main__.py", line 3, in <module>
    from .cmdline import parse_cmdline
File ".../venv/lib/python3.13/site-packages/briefcase/cmdline.py", line 6, in <module>
    from briefcase.commands import DevCommand, NewCommand, UpgradeCommand
File ".../venv/lib/python3.13/site-packages/briefcase/commands/__init__.py", line 1, in <module>
    from .build import BuildCommand  # noqa
File ".../venv/lib/python3.13/site-packages/briefcase/commands/build.py", line 5, in <module>
    from .base import BaseCommand, full_options
File ".../venv/lib/python3.13/site-packages/briefcase/commands/base.py", line 14, in <module>
    import faker
ModuleNotFoundError: No module named 'faker'

Was ist passiert? Wir haben httpx zu unserem Code hinzugefügt, aber wir haben es nicht zu unserer virtuellen Entwicklungsumgebung hinzugefügt. Wir können dies beheben, indem wir httpx mit pip installieren und dann briefcase dev erneut ausführen:

macOSLinuxWindowsAndroidiOS

(beeware-venv) $ python -m pip install faker
(beeware-venv) $ briefcase dev

Wenn Sie einen Namen eingeben und auf die Schaltfläche drücken, sollte ein Dialogfeld angezeigt werden, das etwa so aussieht:

Wir haben jetzt eine funktionierende Anwendung, die eine Bibliothek eines Drittanbieters verwendet und im Entwicklungsmodus läuft!

Ausführen der aktualisierten Anwendung

Lassen Sie uns diesen aktualisierten Anwendungscode als eigenständige Anwendung verpacken. Da wir Änderungen am Code vorgenommen haben, müssen wir die gleichen Schritte wie in Tutorial 4 ausführen:

macOSLinuxWindowsAndroidiOS

Aktualisieren Sie den Code in der gepackten Anwendung:

(beeware-venv) $ briefcase update

[helloworld] Updating application code...
...

[helloworld] Application updated.

Bauen Sie die Anwendung neu auf:

(beeware-venv) $ briefcase build

[helloworld] Adhoc signing app...
[helloworld] Built build/helloworld/macos/app/Hello World.app

Und schließlich führen Sie die Anwendung aus:

(beeware-venv) $ briefcase run

[helloworld] Starting app...
===========================================================================

Wenn die Anwendung jedoch ausgeführt wird, wird in der Konsole ein Fehler und ein Absturzdialog angezeigt:

Wieder einmal ist der Start der Anwendung fehlgeschlagen, weil httpx installiert wurde - aber warum? Haben wir httpx nicht schon installiert?

Das haben wir - aber nur in der Entwicklungsumgebung. Ihre Entwicklungsumgebung befindet sich ausschließlich auf Ihrem Rechner - und wird nur aktiviert, wenn Sie sie explizit aktivieren. Obwohl Briefcase einen Entwicklungsmodus hat, ist der Hauptgrund für die Verwendung von Briefcase, Ihren Code zu verpacken, damit Sie ihn an jemand anderen weitergeben können.

Der einzige Weg, um zu garantieren, dass jemand anderes eine Python-Umgebung hat, die alles enthält, was er braucht, ist, eine vollständig isolierte Python-Umgebung zu erstellen. Das bedeutet, dass es eine komplett isolierte Python-Installation und einen komplett isolierten Satz von Abhängigkeiten gibt. Das ist es, was Briefcase baut, wenn Sie briefcase build ausführen - eine isolierte Python Umgebung. Das erklärt auch, warum httpx nicht installiert ist - es wurde in Ihrer Entwicklungsumgebung installiert, aber nicht in der gepackten Anwendung.

Wir müssen also Briefcase mitteilen, dass unsere Anwendung eine externe Abhängigkeit hat.

Aktualisieren von Abhängigkeiten

Im Hauptverzeichnis Ihrer Anwendung befindet sich eine Datei namens pyproject.toml. Diese Datei enthält alle Konfigurationsdetails der Anwendung, die Sie beim Ausführen von briefcase new angegeben haben.

pyproject.toml ist in Abschnitte unterteilt; einer der Abschnitte beschreibt die Einstellungen für Ihre Anwendung:

[tool.briefcase.app.helloworld]
formal_name = "Hello World"
description = "A Tutorial app"
long_description = """More details about the app should go here.
"""
sources = ["src/helloworld"]
requires = []

Die Option requires beschreibt die Abhängigkeiten unserer Anwendung. Es handelt sich um eine Liste von Strings, die Bibliotheken (und optional die Versionen) der Bibliotheken angeben, die Sie in Ihre Anwendung aufnehmen möchten.

Ändern Sie die Einstellung requires so, dass sie lautet:

requires = [
    "faker",
]

Durch Hinzufügen dieser Einstellung teilen wir Briefcase mit: „Wenn du meine Anwendung baust, führe pip install httpx in das Anwendungsbündel ein“. Alles, was eine legale Eingabe für pip install wäre, kann hier verwendet werden - Sie könnten also angeben:

• Eine bestimmte Bibliotheksversion (z.B. "httpx==0.19.0");

• Eine Reihe von Bibliotheksversionen (z.B. "httpx>=0.19");

• Ein Pfad zu einem Git-Repository (z. B. "git+https://github.com/encode/httpx"); oder

• Ein lokaler Dateipfad (Aber Achtung: Wenn Sie Ihren Code an jemand anderen weitergeben, existiert dieser Pfad wahrscheinlich nicht auf dessen Rechner!)

Weiter unten in pyproject.toml werden Sie andere Abschnitte bemerken, die vom Betriebssystem abhängig sind, wie [tool.briefcase.app.helloworld.macOS] und [tool.briefcase.app.helloworld.windows]. Diese Abschnitte haben auch eine requires Einstellung. Diese Einstellungen erlauben es Ihnen, zusätzliche plattformspezifische Abhängigkeiten zu definieren - wenn Sie also zum Beispiel eine plattformspezifische Bibliothek benötigen, um einen Aspekt Ihrer Anwendung zu behandeln, können Sie diese Bibliothek im plattformspezifischen requires-Abschnitt angeben, und diese Einstellung wird nur für diese Plattform verwendet. Sie werden feststellen, dass die toga-Bibliotheken alle im plattformspezifischen requires-Abschnitt angegeben sind - das liegt daran, dass die Bibliotheken, die für die Anzeige einer Benutzeroberfläche benötigt werden, plattformspezifisch sind.

In unserem Fall wollen wir, dass httpx auf allen Plattformen installiert wird, also verwenden wir die Einstellung requires auf Anwendungsebene. Die Abhängigkeiten auf Anwendungsebene werden immer installiert; die plattformspezifischen Abhängigkeiten werden zusätzlich zu den Abhängigkeiten auf Anwendungsebene installiert.

Nun, da wir Briefcase über unsere zusätzlichen Anforderungen informiert haben, können wir versuchen, unsere Anwendung erneut zu paketieren. Vergewissern Sie sich, dass Sie Ihre Änderungen in pyproject.toml gespeichert haben, und aktualisieren Sie Ihre Anwendung erneut - dieses Mal mit dem Flag -r. Dadurch wird Briefcase angewiesen, die Anforderungen in der gepackten Anwendung zu aktualisieren:

macOSLinuxWindowsAndroidiOS

(beeware-venv) $ briefcase update -r

[helloworld] Updating application code...
Installing src/hello_world...

[helloworld] Updating requirements...
Collecting faker
  Using cached faker-37.3.0-py3-none-any.whl.metadata (15 kB)
...
Installing collected packages: tzdata, travertino, std-nslog, rubicon-objc, fonttools, toga-core, faker, toga-cocoa
Successfully installed faker-37.3.0 fonttools-4.58.1 rubicon-objc-0.5.1 std-nslog-1.0.3 toga-cocoa-0.5.1 toga-core-0.5.1 travertino-0.5.1 tzdata-2025.2

[helloworld] Removing unneeded app content...
...

[helloworld] Application updated.

Sobald Sie das Update durchgeführt haben, können Sie briefcase build und briefcase run ausführen - und Sie sollten Ihre gepackte Anwendung mit dem neuen Dialogverhalten sehen.

Bemerkung

Die Option -r zum Aktualisieren der Anforderungen wird auch von den Befehlen build und run beachtet. Wenn Sie also in einem Schritt aktualisieren, bauen und ausführen wollen, können Sie briefcase run -u -r verwenden.

Third-Party Python Packages for Mobile and Web

Faker is just one example of a third-party Python package - a collection of code that isn’t part what Python provides out of the box. These third-party packages are most commonly distributed using the Python Package Index (PyPI), and installed into your local virtual environment. We’ve been using pip in this tutorial, but there are other options.

Auf Desktop-Plattformen (macOS, Windows, Linux) kann jede pip-Installation zu Ihren Anforderungen hinzugefügt werden. Auf mobilen und Web-Plattformen sind Ihre Möglichkeiten etwas eingeschränkt <https://briefcase.readthedocs.io/en/latest/background/faq.html#can-i-use-third-party-python-packages-in-my-app>`__.

In short; any pure Python package (i.e. any package created from a project written only in Python) can be used without difficulty. Some packages, though, are created from projects that contain both Python and other languages (e.g. C, C++, Rust, etc). Code written in those languages needs to be compiled to platform-specific binary modules before it can be used, and those pre-compiled binary modules are only available on specific platforms. Mobile and web platforms have very different requirements than „standard“ desktop platforms. At this time, most Python packages don’t provide pre-compiled binaries for mobile and web platforms.

On PyPI, packages are often provided in a pre-built distribution format called wheels. To check whether a package is pure Python, look at the PyPI downloads page for the project. If the wheels provided have a -py3-none-any.whl suffix (e.g., Faker), then they are pure Python wheels. However, if the wheels have version and platform-specific extensions (e.g., Pillow, which has wheels with suffixes like -cp313-cp313-macosx_11_0_arm64.whl and -cp39-cp39-win_amd64.whl), then the wheel contains a binary component. That package cannot be installed on mobile or web platforms unless a wheel compatible with those platforms has been provided.

At this time, most binary packages on PyPI don’t provide mobile- or web-compatible wheels. To fill this gap, BeeWare provides binaries for some popular binary modules (including numpy, pandas, and cryptography). These wheels are not distributed on PyPI, but Briefcase will install those wheels if they’re available.

BeeWare kann Binärdateien für einige beliebte Binärmodule (einschließlich numpy, pandas und cryptography) bereitstellen. Es ist normalerweise möglich, Pakete für mobile Plattformen zu kompilieren, aber es ist nicht einfach einzurichten - das würde den Rahmen eines einführenden Tutorials wie diesem sprengen.

Nächste Schritte

We’ve now got an app that uses a third-party library! In Tutorial 8 we’ll learn how to ensure our app remains responsive as we add more complex application logic.