Kann man bei Imports lokale Module bevorzugen?

[vocoder]

Hi Leute,
jetzt kommt wieder eine "ich kann ein Modul nicht importieren" Frage...

Für ein selbst entwickeltes Webapp habe ich die neueste Version von SQLAlchemy im Verzeichnis /meinapp/lib/ installiert und dieses auch zum PYTHONPATH hinzugefügt. Die anderen Module importieren SQLAlchemy wahlweise als

Code: Alles auswählen

from sqlalchemy import *

oder

Code: Alles auswählen

from lib.sqlalchemy import *

. Das hat auch bisher alles gut funktioniert.

Jetzt habe ich über die Paketverwaltung meiner Distro ein anderes Programm installiert, das als Abhängigkeit auch SQLAlchemy hatte, welches deshalb mit installiert wurde, leider in einer älteren Version!

Seitdem funktionieren die Imports meines Webapps nicht mehr, weil anscheinend versucht wird bei

Code: Alles auswählen

from sqlalchemy import *

zuerst auf die alte Distro-Version zuzugreifen, Beispiel:

Code: Alles auswählen

from sqlalchemy.orm import configure_mappers
ImportError: cannot import name configure_mappers

Kann mir jemand vielleicht helfen?

vocoder

[nomnom]

Ich denke, dass sich für dich ein Blick auf virtualenv lohnen könnte.

[vocoder]

Danke für den Vorschlag. Das schaue ich mir mal an.

Ist es der einzige Weg oder kann man auch was in den __init__.py Dateien einstellen, damit lokale Pfade bevorzugt werden oder lokal importierte Module nicht nochmal geladen werden?

[nomnom]

Ist es der einzige Weg oder kann man auch was in den __init__.py Dateien einstellen, damit lokale Pfade bevorzugt werden oder lokal importierte Module nicht nochmal geladen werden?

Man könnte das Programm auch mit einer Angabe zum $PYTHONPATH starten, dann würde, glaube ich, erst da geguckt, ob da was ist.

[cofi]

In dem Fall wird nicht mal eine Installation gegenueber der anderen bevorzugt: Deine Lokale sqlalchemy Installation befindet sich nicht im Python-Path. Das merkt man schon daran, dass du `lib.sqlalchemy` statt `sqlalchemy` importieren musst.

Was du aendern kannst ist im Tutorial beschrieben: http://docs.python.org/tutorial/modules ... earch-path

[lunar]

Du kannst relative Imports nach PEP 328 nutzen. Ohne zwingenden Grund würde ich allerdings davon absehen, Abhängigkeiten im eigenen Programm als Paket mitzuliefern. Installiere die Abhängigkeiten lieber anständig, und nutze eigene Python-Umgebungen mit virtualenv zur Entwicklung und falls möglich zum Deployment Deiner Anwendungen.

[vocoder]

@cofi
War vielleicht mißverständlich, nochmal zur Klärung: ich konnte aus der lokalen SQLAlchemy Installation mit 'from lib.sqlalchemy...' oder 'from sqlalchemy...' importieren. In __init__.py im Verzeichnis 'lib' steht:

Code: Alles auswählen

import sys
sys.path += __path__

So wie ich das verstehe, wird damit /meinapp/lib dem PYTHONPATH hinzugefügt. Kann es sein, dass 'sys.path += __path__' den Projektpfad hinten an den Suchpfad anfügt statt ihn an den Anfang zu stellen? Das würde erklären, warum zuerst auf die dist-packages zugegriffen...

@lunar
Mein App wird auf einem Shared Hoster laufen wo ich keine eigenen Pakete installieren kann...

[Leonidas]

Mein App wird auf einem Shared Hoster laufen wo ich keine eigenen Pakete installieren kann...

Dann installier die Abhängigkeiten Lokal in einen Ordner und füge diesen in den PYTHONPATH ein. Aber fremde Pakete im eigenen Paket mitliefern ist eher ein No-No.

[vocoder]

@Leonidas
Kann ich machen. Ist das nur eine Konvention, dass man fremde Pakete im eigenen nicht mitliefert, oder gibt es auch technische Gründe dafür?

[BlackJack]

@vocoder: Der technische Grund dass das *so* offensichtlich nicht funktioniert reicht Dir nicht!?

[Leonidas]

oder gibt es auch technische Gründe dafür?

Ja. Unnötige Code-Duplikation (wenn man die Pakete auch einmal für alle Programme installieren kann statt dass jedes Programm seine tausend Depenencies jedes mal mitschleppt), Sicherheit (wenn das Paket aktualisiert wird wegen Sicherheitsupdates musst du schauen dass du das aktualisierst und allen Usern wieder neu andrehst, das ist ein ziemliches Problem etwa mit zlib und libpng wo man idR unter Windows 27 Kopien davon hat und die meisten Sicherheitslücken enthalten).