Wie erstelle ich ein Namespace-Paket in Python?

Question

In Python können Sie mit einem Namespace-Paket Python-Code auf mehrere Projekte verteilen. Dies ist nützlich, wenn Sie verwandte Bibliotheken als separate Downloads freigeben möchten. Zum Beispiel mit den Verzeichnissen Package-1 und Package-2 in PYTHONPATH,

Package-1/namespace/__init__.py 
Package-1/namespace/module1/__init__.py 
Package-2/namespace/__init__.py 
Package-2/namespace/module2/__init__.py 

der Endanwender kann import namespace.module1 und import namespace.module2.

Wie kann ein Namespace-Paket am besten definiert werden, sodass mehr als ein Python-Produkt Module in diesem Namespace definieren kann?

Answer 1

Es gibt ein Standardmodul, genannt pkgutil, mit dem Sie können ‚append‘ Module zu einem bestimmten Namespace.

Mit der Verzeichnisstruktur Sie zur Verfügung gestellt haben:

Package-1/namespace/__init__.py 
Package-1/namespace/module1/__init__.py 
Package-2/namespace/__init__.py 
Package-2/namespace/module2/__init__.py 

Sie sollten sowohl Package-1/namespace/__init__.py und Package-2/namespace/__init__.py (*), diese beiden Linien setzen: seit

from pkgutil import extend_path 
__path__ = extend_path(__path__, __name__) 

(* -Außer Sie angeben, ein Abhängigkeit zwischen ihnen - Sie wissen nicht, welche von ihnen zuerst erkannt wird - siehe PEP 420 für weitere Informationen)

Wie die documentation sagt:

Diese __path__ alle Unterverzeichnisse von Verzeichnissen auf sys.path nach dem Paket mit dem Namen auf der Verpackung des hinzufügen.

Von nun an sollten Sie in der Lage sein, diese beiden Pakete unabhängig voneinander zu verteilen.

Answer 2

Sie haben Ihre Python-Namespace-Konzepte von vorne nach hinten, es ist in Python nicht möglich, Pakete in Module zu setzen. Pakete enthalten Module nicht umgekehrt.

Ein Python-Paket ist einfach ein Ordner mit einer __init__.py Datei. Ein Modul ist eine beliebige andere Datei in einem Paket (oder direkt auf der PYTHONPATH), die eine .py Erweiterung hat. In Ihrem Beispiel haben Sie also zwei Pakete, aber keine Module definiert. Wenn Sie in Betracht ziehen, dass ein Paket ein Dateisystemordner und ein Modul eine Datei ist, sehen Sie, warum Pakete Module enthalten und nicht umgekehrt.

So in Ihrem Beispiel unter der Annahme, Package-1 und Package-2 sind Ordner auf dem Dateisystem, das Sie auf dem Python-Pfad gesetzt haben, können Sie folgende Voraussetzungen erfüllt sein:

Package-1/ 
    namespace/ 
    __init__.py 
    module1.py 
Package-2/ 
    namespace/ 
    __init__.py 
    module2.py 

Sie haben jetzt ein Paket namespace mit zwei Module module1 und module2. und es sei denn, Sie haben einen guten Grund sollten Sie wahrscheinlich die Module im Ordner abgelegt und nur, dass auf dem Python-Pfad wie unten:

Package-1/ 
    namespace/ 
    __init__.py 
    module1.py 
    module2.py 

Answer 3

This section should be pretty self-explanatory.

Kurz gesagt, stellen Sie den Namespace Code in __init__.py, aktualisieren setup.py einen Namespace zu deklarieren, und Sie sind frei zu gehen.

Answer 4

Dies ist eine alte Frage, aber jemand vor kurzem auf meinem Blog kommentiert, dass mein Posting über Namespace-Pakete noch relevant war, dachte so würde ich auf sie verwiesen wird hier, wie es ein praktisches Beispiel dafür, wie sieht, um es gehen:

http://cdent.tumblr.com/post/216241761/python-namespace-packages-for-tiddlyweb

, die für die Haupt Eingeweide zu diesem Artikel verknüpft, was los ist:

http://www.siafoo.net/article/77#multiple-distributions-one-virtual-package

der __import__("pkg_resources").declare_namespace(__name__) Trick ist so ziemlich treibt die Verwaltung von Plugins in TiddlyWeb und scheint bis jetzt zu funktionieren.

Answer 5

TL; DR:

auf Python 3.3 Sie setzen nicht alles tun, nur keine __init__.py in Ihren Verzeichnissen Namespace-Paket und es wird funktionieren nur. Wählen Sie vor Version 3.3 die pkgutil.extend_path()-Lösung über die pkg_resources.declare_namespace(), da diese zukunftssicher und bereits mit impliziten Namespacepaketen kompatibel ist.

---

Python 3.3 führt implizite Namespace-Pakete, PEP 420 sehen.

Dies bedeutet, dass es nun drei Arten von Objekten sind, die von einer import foo erstellt werden können:

• Ein Modul durch eine Datei foo.py dargestellt
• Ein regelmäßiges Paket von einem Verzeichnis dargestellt foo eine __init__.py Datei enthält,
• Ein Namespace-Paket,
durch ein oder mehrere Verzeichnisse foo ohne __init__.py Dateien dargestellt

Pakete sind auch Module, aber hier meine ich "Nicht-Paket-Modul", wenn ich "Modul" sage.

Zuerst scannt sys.path für ein Modul oder ein reguläres Paket. Wenn es erfolgreich ist, hört es auf zu suchen und erstellt und initialisiert das Modul oder Paket. Wenn kein Modul oder reguläres Paket gefunden wurde, aber mindestens ein Verzeichnis gefunden wurde, wird ein Namespacepaket erstellt und initialisiert.

Module und reguläre Pakete haben __file__ auf die .py Datei festgelegt, aus der sie erstellt wurden. Reguläre und Namespacepakete haben __path__ auf das Verzeichnis oder die Verzeichnisse festgelegt, aus denen sie erstellt wurden.

Wenn Sie import foo.bar tun, die oben Suche geschieht zuerst für foo, dann, wenn ein Paket gefunden wurde, die Suche nach bar mit foo.__path__ als Suchpfad getan statt sys.path. Wenn foo.bar gefunden wird, werden foo und foo.bar erstellt und initialisiert.

Wie also mischen sich reguläre Pakete und Namespacepakete? Normalerweise nicht, aber die alte pkgutil explizite Namespace-Paketmethode wurde um implizite Namespacepakete erweitert.

Wenn Sie ein vorhandenes reguläres Paket, das ein __init__.py so hat:

from pkgutil import extend_path 
__path__ = extend_path(__path__, __name__) 

... das Vermächtnis Verhalten andere regelmäßig Pakete auf dem gesuchten Weg zu seinem __path__ hinzuzufügen. Aber in Python 3.3 fügt es auch Namespacepakete hinzu.

So können Sie die folgende Verzeichnisstruktur haben:

├── path1 
│   └── package 
│    ├── __init__.py 
│    └── foo.py 
├── path2 
│   └── package 
│    └── bar.py 
└── path3 
    └── package 
     ├── __init__.py 
     └── baz.py 

... und solange die beiden __init__.py haben die extend_path Linien (und path1, path2 und path3 sind in Ihrem sys.path) import package.foo, import package.bar und import package.baz wird alles funktionieren.

pkg_resources.declare_namespace(__name__) wurde nicht aktualisiert, um implizite Namespacepakete einzuschließen.