Grundsätzliche Frage zur Strukturierung von Python-Projekten

[__LC__]

Moin liebe Python-Freunde.

Ich habe mal eine grundsätzliche Frage zwecks der Verwaltung und Strukturierung verschiedener Python-Projekte. Soweit ich das jetzt an verschiedenen Stellen gelesen habe, wird ein grober Aufbau eines Python-Projektes wie folgt vorgeschlagen:
[codebox=text file=Unbenannt.txt]
PROJECT
|- docs
|- bin
|- lib
|- project
| |-- __init__.py
| |-- main.py
| |-- test
| |-- test_main.py
|- .gitignore
|- LICENSE.txt
|- README.rst
|- requirements.txt
|- setup.py
[/code]

Nun stellt sich aber für mich die Frage, wie handhabt ihr dass mit einzelnen Modulen/Packages, die zukünftig auch Projekt-übergreifend ohne Code-Duplizierung verwendet werden sollen? Anlehnend an meine aktuelle Aufgabenstellung denke ich da beispielsweise an einzelne Module für Elektronikbausteine (I2C) für den Raspberry Pi. Sollten diese dann eher in einem eigenen Projekt 'Commons' oder so verwaltet werden?

Über ein paar Anregungen bzw. konkrete Erfahrung hierzu würde ich mich sehr freuen. Danke euch.

Schöne Grüße

[BlackJack]

@__LC__: In ein eigenes Projekt auslagern, oder auch Mehrere. Informiere Dich dazu mal über „namespace packages”.

[__LC__]

[codebox=text file=Unbenannt.txt][/code]Hallo BlackJack.

Vielen Dank für deinen Hinweis mit den "namespace packages". Allerdings ergeben sich dann gleich wieder die ersten Anschlussfragen zu dem Thema.
Wenn ich es jetzt richtig verstanden habe, gibt es doch nun 2 Möglichkeiten um projektübergreifend einen gemeinsamen "Namespace" aufzubauen.

Code: Alles auswählen

PROJECT_1
    |- docs
    |- bin
    |- lib
    |- project_1
    |   |-- NAMESPACE
    |      |-- module_1.py
    |   |-- test
    |       |-- test_module_1.py
    |- .gitignore
    |- LICENSE.txt
    |- README.rst
    |- requirements.txt
    |- setup.py

PROJECT_2
    |- docs
    |- bin
    |- lib
    |- project_2
    |   |-- NAMESPACE
    |      |-- module_2.py
    |   |-- test
    |       |-- test_module_2.py
    |- .gitignore
    |- LICENSE.txt
    |- README.rst
    |- requirements.txt
    |- setup.py

Eine andere Möglichkeit um gleiches Resultat zu erzielen wäre dann doch

Code: Alles auswählen

PROJECT_1
    |- docs
    |- bin
    |- lib
    |- NAMESPACE
    |   |-- __init__.py
    |   |-- module_1.py
    |   |-- test
    |       |-- test_module_1.py
    |- .gitignore
    |- LICENSE.txt
    |- README.rst
    |- requirements.txt
    |- setup.py

PROJECT_2
    |- docs
    |- bin
    |- lib
    |- NAMESPACE
    |   |-- __init__.py
    |      |-- module_2.py
    |   |-- test
    |       |-- test_module_2.py
    |- .gitignore
    |- LICENSE.txt
    |- README.rst
    |- requirements.txt
    |- setup.py

wobei beide __init__.py
[codebox=pycon file=Unbenannt.txt]from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)[/code]
enthalten müssen. Oder habe ich doch einen Denkfehler?

Schöne Grüße

[Sirius3]

@__LC__: statt "projektübergreifend" kann man ja auch "projektunabhängig" schreiben. Wenn Projekt A und Projekt B teilweise das selbe machen, dann mußt Du das selbe in ein Modul C auslagern, das völlig unabhängig von A und B ist und dort nur importiert wird.

[__LC__]

Hallo Sirius.

Das genau ist eigentlich mein Ziel. Vielleicht habe ich mich da nicht ganz deutlich ausgedrückt.
Was ich aber auch gern noch erreichen würde, wäre die logische Zugehörigkeit aller Module der verschiedenen Projekte in einen "zusammengehörigen" Namensraum, so dass spätere Imports nach dem Muster 'myspace.rpi import Dummy' oder 'myspace.networking import TCPServer' möglich sind. Das wäre soweit ich das jetzt richtig verstanden habe die Version 2 meines letzten Beitrages.

Schöne Grüße

[DasIch]

Das ganze ist doch überhaupt nicht kompliziert, wenn du zwei Projekte hast die sich Code teilen, erstellst du einfach ein weiteres Projekt oder weitere Projekte, falls der sich überschneidende Teil nicht in direktem Zusammenhang steht.

Dieses Projekt lädst du dann entweder auf PyPI oder einem privaten PyPI Server hoch.

Von Namespace Packages um deinen persönlichen Namespace zu haben würde ich abraten, sowas driftet recht schnell zu "Persönliches Notizbuch zum herum kritzeln" ab indem ganz viel NIH betrieben wird, wobei dass Ziel ja eigentlich unabhängige wiederverwendbare Projekte sind.