Paket Struktur Teamprojekt

[rogerb]

Hallo zusammen,

ich denke gerade darüber nach was die beste Paketstruktur für ein kleines Projekt wäre.
Ich habe mich grob hieran orientiert:
https://docs.python-guide.org/writing/structure/

Es gibt aber ein paar Unterschiede.
1. Kein eigentliches packaging und hosting auf PyPi
2. Das Sample-Paket wird über die gesamte Lebensdauer in einem Git Repository leben
3. Das Sample-Paket muss nur selten, bei Bedarf angepasst werden. Es stellt eine Library zur Verfügung, welches von den User-Skripten genutzt wird.
4. Einige Nutzer arbeiten sowohl am Sample-Paket als auch an den User-Skripten und teilen die Arbeitsergebnisse über das Git Repository
5. Obwohl die User-Scripte nicht zum Sample-Paket gehören, sollen sie auch über das Git Repository mit anderen geteilt werden können.
6. Zur Verwaltung externer Pakete gibt es ein venv. Sowohl das Sample-Paket als auch die User-Scripte benötigen externe Pakete daraus.
7. User-Skripte werden öfter geändert, sollen aber hauptsächlich über die Config-Dateien manipuliert werden können.
8. Ich kann mir auch getrennte Repositories vorstellen, wenn es gute Gründe gibt.

Code: Alles auswählen

| requirements.txt
| .git/
| .gitignore
| sample/
    | __init__.py
    | core.py
    | something.py
    | something_else.py
    | utilities/
         | __init__.py
         | some_utility_stuff.py
         | some_other_utility_stuff.py
    | docs/
         | conf.py
         | index.md
    | tests/
         | test_basic.py
         | test_advanced.py

| venv/
| user-script1.py
| user-script2.py
| user-script3.py
| some_config1.json
| some_config2.json
| some_config3.json

Fallen euch dabei irgendwelche Nachteile auf? Kann man es unter den Voraussetzungen besser machen?
Edit: Der Linke war mir irgendwie missglückt, passt jetzt. Framework war falsch, Library trifft es besser.

[__deets__]

Das venv hat darin nichts verloren. Denn das ist ja je nach system unterschiedlich. Um die zu managen gibt es zb pipenv. Auch die Dokumentation würde ich nicht in die Quellen packen. Sondern daneben. Und erst recht nicht vermischen mit Quellcode. Sowohl für die Skripte als auch die Konfigurationen würde ich jeweils einen unterordner erstellen. Oder gleich ein setup.py-basiertes console entry point. Dann fallen die als Datei weg.

[rogerb]

@__deets__, den letzten Punkt verstehe ich nicht.

Oder gleich ein setup.py-basiertes console entry point. Dann fallen die als Datei weg.

Du meinst Argumente zum Beispiel mit argparse zu übergeben statt aus Konfigurationsdateien zu lesen? Das wären einerseits zu viele Parameter andererseits ändern sich oft nur einige. In einer JSON-Datei kann man ja auch schön sehen was gerade konfiguriert ist.

[rogerb]

Noch eine Frage:
Wenn ich die User-Scripte in einem eigenen Ordner unterbringe und dieser Ordner, dann mit dem Sample-Paketordner in einem gemeinsamen Ordner liegt, bekomme ich das Problem, dass ich nicht mehr einfach aus dem Sample-Paket importieren kann.
Was ist die beste Methode den Sample-Paket Pfad dem PYTHONPATH hinzuzufügen.
Ich kann sys.path.append() machen, oder direkt in die Umgebungsvariablen speichern. Wie sieht es aus mit einer *.pth Datei in site-packages? Es gibt ja einige Möglichkeiten, aber welche bietet sich an?
Ist es wirklich eine gute Idee Sample-Paketordner und User-Scriptordner auf einer Ebene im gleichen umfassenden Ordner zu haben?

[__deets__]

Mit entry points meine ich etwas anderes: https://stackoverflow.com/questions/774 ... try-points

Die kann man mit “python setup.py develop” auch so anlegen, dass sie im venv sind, aber Code-Änderungen weiterhin bemerkt werden. Das ist wohl deprecated, aber so habe ich es seit langem gehalten. Ich muss man nachlesen, was der neue Weg ist.

Wenn man das nicht will oder kann, nehme ich sys.path. Es ist natürlich eine Geschmacksfrage, ich bevorzuge eben weniger files im root. Eine PTH Datei ist letztlich was das develop oben macht.

Ob JSON oder Argumente für deinen anwendungsfall besser sind oder nicht, kann ich nicht beurteilen. Darauf habe ich mich also auch nicht bezogen.

[__deets__]

https://setuptools.pypa.io/en/latest/us ... ml#develop beschreibt develop. Leider finde ich gerade den blogpost einer der maintainer nicht mehr, der sich dagegen ausgesprochen hat. Da ging es hauptsächlich um die Trennung von front end und backend, aber das war da auch erwähnt.

[Sirius3]

Das Paket sollte eh ins venv installiert werden, so dass die Userskripte automatisch den Pfad finden.
Wenn je eine Konfig zu einem Skript gehört, dann wäre es vielleicht sogar sinnvoll unter dem scripts/-Pfad weitere Unterverzeichnisse zu haben.

[__deets__]

Ah, endlich: https://blog.ganssle.io/category/programming.html

pip install -e

[rogerb]

@__deets__, @Sirius3,
danke euch für die Anregungen. "pip install -e " Scheint gut zu dem zu passen, was ich mir vorstelle, jedenfalls ist das jetzt mein Eindruck.
Ich hoffe, dass die Flexibilität dabei erhalten bleibt, denn wenn man schnell von einem Branch zum anderen wechselt, will man ja nach dem checkout gleich weiter arbeiten können.