Quellcode-Datei auswerten

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Benutzeravatar
pixewakb
User
Beiträge: 1408
Registriert: Sonntag 24. April 2011, 19:43

Ich muss eine Art Inventur meiner Python-Skripte machen. Im Kern werte ich aus, ob das Coding definiert ist, wie viele Codezeilen enthalten sind, dann muss ich aber auch auswerten, welche Bibliotheken genutzt werden und zwar nach Bibliotheken, die (1) mit Python installiert wurden, (2) installierte Fremdbibliotheken und (3) eigenen Bibliotheken. Und einige sehr spezielle Sachen (konkreter Einsatz bestimmter Bibliotheken usw.).

Zweck ist ein angedachtes Refactoring, wobei die Skripte vereinheitlicht werden sollen. Ferner soll - falls mal eine Bibliothek ausfällt -, gesagt werden können, welche Bereiche und konkret welche Skripte betroffen sind.

Ich stricke mir gerade schon etwas, was absehbar die Aufgaben erledigt. Die Wünsche sind sehr speziell, so dass fertige Lösungen wahrscheinlich nicht in Frage kommen. Dennoch - bevor ich das Rad neu erfinde - gibt es da fertige Lösungen? Und wenn es nur für Anregungen ist.

Danke.
nezzcarth
User
Beiträge: 1632
Registriert: Samstag 16. April 2011, 12:47

Die importierten Bibliotheken kannst du dir (allerdings inkl. Abhängigkeiten) z.B. mit modulefinder aus der Standardbibliothek anzeigen lassen.

Wenn ich so etwas, wie das, was du beschreibst machen muss, verwende ich gängige Unix-Tools (find/locate, xargs, grep … größere Mengen reguläre Ausdrücke). Das ist natürlich schon etwas Gebastel, funktioniert aber ausreichend; in der Regel ist das ja nur eine Vorarbeit für die eigentliche Aufgabenstellung.
Benutzeravatar
pixewakb
User
Beiträge: 1408
Registriert: Sonntag 24. April 2011, 19:43

Danke für den Hinweis! Ich nutze Python auf einem Windows-System, so dass mir entsprechende Tools nicht zur Verfügung stehen. Ich kann die Sachen, die ich brauche händisch (mit if-Abfragen bzw. auch reguläre Ausdrücke) einbauen. Ich hatte befürchtet, dass es für so etwas fertige Lösungen gibt; deine Antwort beruhigt mich.

Das Ergebnis ist ein Bericht - entweder HTML-Bericht (wahrscheinlich) oder ein Tabellendokument -, es geht halt um einen Überblick, dann eine Verbesserung der vorhandenen Funktionalität und dann um eine Kontrolle, was wo wie gemacht, gebraucht und ggf. repariert werden muss. (In der Hauptsache soll eigentlich die Migration der Skripte auf ein anderes System vorbereitet werden und zudem die Wartbarkeit verbessert werden.)

Danke!!!
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Mit zb msys git (eh git zur Verwaltung des Skripte Zoos) hast du alle diese Tools.

Zum parsen ggf auch mal auf das ast Modul gucken.
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

@pixewakb: jedes Paket sollte eine requirements.txt-Datei haben, das alle Abhängigkeiten (inklusive Versionen) auflistet; damit hat man diese in einem maschinenlesbaren Format. Interne und externe Abhängigkeiten kann man durch Kommentare trennen. Gerade die Versionsfrage ist kaum automatisiert erledigbar. Um zu testen, ob man die alle Abhängigkeiten richtig aufgelöst hat, erzeugt man sich ein frisches Virtual-Env und läßt dort alle Tests laufen. Um Bibliotheken migrieren zu können, ist sowieso eine möglichst komplette Testabdeckung nötig.
Derjenige, der die Bibliothek betreut, wird die Abhängigkeiten kennen, so dass ich den Nutzen einer Automatisierung hier nicht erkennen kann.
Benutzeravatar
pixewakb
User
Beiträge: 1408
Registriert: Sonntag 24. April 2011, 19:43

Sirius3 hat geschrieben:@pixewakb: jedes Paket sollte eine requirements.txt-Datei haben, das alle Abhängigkeiten (inklusive Versionen) auflistet; damit hat man diese in einem maschinenlesbaren Format. Interne und externe Abhängigkeiten kann man durch Kommentare trennen. Gerade die Versionsfrage ist kaum automatisiert erledigbar. Um zu testen, ob man die alle Abhängigkeiten richtig aufgelöst hat, erzeugt man sich ein frisches Virtual-Env und läßt dort alle Tests laufen. Um Bibliotheken migrieren zu können, ist sowieso eine möglichst komplette Testabdeckung nötig.
Derjenige, der die Bibliothek betreut, wird die Abhängigkeiten kennen, so dass ich den Nutzen einer Automatisierung hier nicht erkennen kann.
Ich habe mir bereits die Seite zu den requirements.txt-Dateien gebookmarkt und werde das umsetzen.

Mit Virtual-Env habe ich noch nicht gearbeitet, habe ich aber schon mal gesehen, dass man das allein mit Python aufsetzen kann. Momentan hat die Datenauswertung Priorität. Danke für den Hinweis, ist notiert.

Die Testabdeckung läuft noch nicht und wäre eine der Sachen, um die ich mich bald kümmern müsste/möchte.

Momentan bin ich der, der die Bibliotheken betreut (und keinen Überblick hat) und zugleich den Bereich betreut, der die Bibliotheken nutzt. Es gibt momentan < 10 Bibliotheken und wahrscheinlich irgendwas zwischen 30 und 40 Agenten, die die Bibliotheken nutzen und Routine-Aufgaben (Datenabruf, Datenspeicherung und Datenauswertung) erledigen. Ein Teil davon hängt in der Aufgabenverwaltung, die anderen werden nur bei Bedarf manuell gestartet und erledigen dann Wartungs- oder Prüfaufgaben. Ich möchte die Agenten - darum geht es mir momentan in der Hauptsache - auf einen guten, einheitlichen Stand bringen.

Die Agenten sind nicht installiert. Fast alle Agenten erzeugen einen HTML-Report, einige aber auch ein Excel-file. Bei allen Agenten will ich eigentlich bei einem Programmabbruch einen HTML-Report, der mir mitteilt, dass ein Fehler aufgetreten ist. Hintergrund ist, dass die Agenten in der Aufgabenplanung hängen und manche nur einmal im Monat ausgeführt werden. Das habe ich noch nicht überall (ich weiß nicht, wo) umgesetzt und so könnte ich über Monate ein Loch in meiner Datenabdeckung bekommen, ohne dass es mir direkt auffällt. (Darum möchte ich eine möglichst automatisierte Abdeckung, um solche Lücken finden zu können...)

PS Ich bin kein studierter Programmierer, mehr so Hobby-Programmierer. Ich habe den Anspruch es möglichst gut zu machen, um mir in Zukunft Probleme zu vermeiden, aber ich nehme wahr, dass da immer (noch) viel Luft nach oben ist.
Antworten