Erstellen eines Python-Pakets für ein C-Erweiterungsmodul, das vordefiniert ist

9

Ich möchte ein Paket für ein Projekt erstellen, das keine .py Quelldateien enthält, aber vollständig als Python C Erweiterung implementiert ist (was zu einem .so führt). Nehmen Sie außerdem an, dass .so bereits von einem separaten Build-Prozess (z. B. CMake) erstellt wurde.

Ich weiß, dass setuptools / distutils minimal eine Verzeichnisstruktur benötigt:

  • mein Modul
    • __ init __. py

Aber was ich wirklich will, ist, dass mymodule von einer C-Erweiterung bereitgestellt wird (zB mymodule.so ), so dass nach der Installation des Pakets import mymodule den gleichen Effekt wie der direkte Import von mymodule.so hat.

Ich weiß, dass ich diese Art von Verzeichnisstruktur haben könnte:

  • mein Modul
    • __ init __. py
    • mymodule_native.so

und __init__.py be:

haben %Vor%

Diese Art von Arbeiten, aber ein Objekt A importiert von mymodule sieht tatsächlich wie mymodule.mymodule_native.A aus.

Gibt es einen direkteren Weg?

    
jogloran 09.08.2017, 21:35
quelle

1 Antwort

1

Es ist möglich, wenn die Erweiterung von setuptools konfiguriert wird.

Zum Beispiel:

%Vor%

Nach der Installation ist die Erweiterung als import mymodule verfügbar. Beachten Sie, dass find_packages nicht verwendet wird.

Dies muss von setuptools erledigt werden, da sonst eine packages Einstellung erforderlich wäre, wenn keine ext_modules bereitgestellt werden.

Allerdings wird das .so -Modul direkt im Verzeichnis site-packages installiert und führt zu einem Konflikt mit allen nicht-erweiterbaren Python-Modulen gleichen Namens.

Dies wird allgemein als schlechte Praxis angesehen und die meisten Bibliotheken verwenden ein reines Python-Modul mit einem einzigen __init__.py , unter dem die Erweiterung verfügbar ist.

Sie können in Zukunft beispielsweise Python-Code zu Ihrem Modul hinzufügen und möchten den reinen Python-Code vom Erweiterungscode trennen. Oder Sie möchten mehr als eine Erweiterung hinzufügen, was auf diese Weise nicht möglich ist, zumindest nicht unter Beibehaltung des gleichen Paketnamens.

Also ist eine Struktur wie mymodule.<python modules> und mymodule.my_extension sinnvoll.

Persönlich hätte ich separate Namensräume für den Erweiterungscode vs. Python-Code und nicht from <ext mod> import * in __init__.py .

    
danny 21.08.2017 10:18
quelle

Tags und Links