2009-03-10 8 views
1

Ich habe ein Modul, das ich auf dem Laufenden halten wollen, und ich frage mich, ob dies eine schlechte Idee ist:automatisch neueste Version einer Datei auf Import holen

Haben Sie ein Modul (mod1.py) in dem site-packages-Verzeichnis, das ein anderes Modul von einem anderen Speicherort in das site-packages Verzeichnis kopiert und dann * dieses Modul importiert.

import shutil 
from distutils.sysconfig import get_python_lib 
p_source = r'\\SourceSafeServer\mod1_current.py' 
p_local = get_python_lib() + r'\mod1_current.py' 
shutil.copyfile(p_source, p_local) 
from mod1_current import * 

Jetzt kann ich das in jedem Modul, und es wird immer die neueste Version sein:

from mod1 import function1 

Das funktioniert .... aber gibt es einen besseren Weg, dies zu tun?

aktualisiert

Hier ist der aktuelle Prozess ... gibt es ein Projekt unter Quellcodeverwaltung, die ein einzelnes Modul hat: mod1.py Es gibt auch eine setup.py Lauf setup.py Kopien mod1.py auf das Website-Pakete Verzeichnis.

Entwickler, die das Modul verwenden, müssen setup.py ausführen, um das Modul zu aktualisieren. Manchmal tun sie es nicht und haben nicht die neueste Version, die Probleme verursacht.

Ich möchte in der Lage sein, nur Check-in der neuen Version, und jeder Code, der das Modul importiert wird automatisch jedes Mal, ohne dass jemand die neueste Version greifen mit setup.py

+0

Was ist falsch mit einer gewöhnlichen "setup.py install"? Warum wird das nicht funktionieren? Was ist Ihr Anwendungsfall dafür? –

+0

Derzeit tun wir dies, um sicherzustellen, dass wir die neueste Version haben.Ich möchte diesen Schritt herausnehmen, da eine alte Version Probleme verursachen kann und manchmal eine Neuinstallation übersehen wird. Schlägst du vor, setup.py automatisch auszuführen? Es würde nur die eine Datei in Site-Pakete kopieren –

+0

@coonj: Bitte aktualisieren Sie Ihre Frage mit zusätzlichen Fakten. Wenn die Installation von setup.py nicht kaputt ist, warum reparieren Sie sie? Welche Probleme haben Sie? –

Antwort

1

In einigen Fällen haben wir .pth Dateien in das Python site-packages-Verzeichnis geschrieben. Die .pth Dateien benennen unsere verschiedenen SVN Checkout-Verzeichnisse.

Keine Installation. Keine Kopie.

.pth Dateien sind beschrieben here.

+0

OK das ist perfekt. Vielen Dank –

2

Haben Sie wirklich laufen willst du das machen? Dies bedeutet, dass Sie den Code sehr einfach in eine Produktionsanwendung rollen können, indem Sie die Quellcodeverwaltung festlegen. Ich würde dies als einen unangenehmen Nebeneffekt für jemanden betrachten, der sich Ihres Setups nicht bewusst ist.

Das scheint eine ziemlich gute Lösung zu sein - Sie können einige Ausnahme-Behandlung rund um die Netzwerk-Dateiaufrufe hinzufügen, da diese anfällig für Fehler sind.

+0

Gute Punkte, danke. Jeder, der dieses spezielle Modul verwendet, greift derzeit auf die neueste Version zurück, so dass dieser Schritt aus dem Prozess genommen wird. Ich denke, es ist wahrscheinlicher, dass Probleme auftreten, wenn Sie die alte Version verwenden und nicht automatisch die neueste verwenden. –

+0

Und ich werde auf jeden Fall die Ausnahmebehandlung hinzufügen. –

0

Die ursprüngliche Strategie, dass andere Entwickler mod1.py in ihre Site-Pakete kopieren, um das Modul zu verwenden, klingt, als wäre es das eigentliche Problem. Warum verwenden sie nicht dieselbe Quellcodeverwaltung wie du?

Dieses automatische Kopieren macht Rollbacks schwierig, besonders wenn andere Entwickler Ihre Strategie kopieren. Stellen Sie sich das gleiche System vor, das für Dutzende von Dateien verwendet wird. Und dann stellen Sie sich vor, Sie tatsächlich tun möchten eine Version von mod1.py verwenden, die nicht die neueste für etwas ist.

Verwandte Themen