[Python-de] Windows: Postgres-Zugriff ohne Server-Installation

Diez Roggisch deets at web.de
Do Apr 11 13:11:52 CEST 2013


On 4/11/13 11:46 AM, "Volker Böhm" <volker at vboehm.de> wrote:

>Am Wed, 10 Apr 2013 22:35:25 +0200 schrieb Diez B. Roggisch:
>
>> Wenn man kein vorkompiliertes Binary von psycopg2 installieren will oder
>> kann, dann muss man wohl oder uebel kompilieren - und zwar gegen die
>> Postgres DB API, Headerfiles sowie DLLs. Dazu braucht man auch unter
>> Linux mindestens die dev-Pakete, ob die fuer den client separat
>> vorliegen mag ich gerade nicht gucken.
>> 
>> pg_config ist ein Programm, btw.
>> 
>> Wieso du aber Stunden brauchst, und dann das hier nicht findest
>> 
>>  http://www.stickpeople.com/projects/python/win-psycopg/
>
>Erstens habe ich mich nie gegen ein vorkompiliertes Binary gewehrt; im
>Gegenteil: Ich suche verzweifelt danach.
>Und außerdem steht auf der genannten Seite - wo ich vorher schon mehrfach
>war - zu lesen: 'Also, it has been noted that the psycopg2 installers do
>not work under a virtualenv environment.' (da fällt cygwin wohl auch
>drunter). 

Nein, hat nichts miteinander zu tun. Ob die Binärtreiber unter Cygwin
*ueberhaupt* funktionieren ist fraglich (bzw tun sie nicht, siehe unten),
aber auf der anderes Seite wiederum ist cygwin unix-aehnlich genug - da
hast du compiler, postgres, libs & dev-kram.

Im übrigen steht auch auf der Seite nicht, dass virtualenvs nicht gehen -
es funktioniert nur nicht mit einem simplen easy_install. Es ist aber
durchaus möglich, die Installer-Binaries in ein venv zu packen.

"""The same method as mentioned above with Zope can be used to extract the
binaries and place them in the <venv_dir>\Lib\site-packages\ directory."""

Und darueber hinaus koenntest du sogar ein egg bauen, wenn du willst.
Händisch, nervt, aber psycopg2 ändert sich ja auch nicht täglich.

Mal abgesehen davon, dass ich psycopg2 immer im Basis-Python drin hatte,
und einfach nur venvs darüber gelegt habe.


> Und probiert hatte ich die Installation damit auch aber es kam
>nur eine schwachsinnige Meldung, in der Registry sei kein Python
>eingetragen.

Die ist nicht schwachsinnig, die liegt an der Verwendung von cygwin, und
dessen Python. Cygwin ist eine komplett eigene Welt, nicht Linux und nicht
Windows. Wenn du das benutzen willst, musst du auch den vollen cygwin Weg
gehen für psycopg2.

 http://www.thebitguru.com/blog/view/265-Getting%20psycopg2%20to%20work%20i
n%20cygwin

>Jede Menge Schwachsinn, der entweder überhaupt keine Grundvoraussetzungen
>erwähnt oder der aufzählt, man möge zuerst Postgres installieren.
>Und einen Postgres-_Server_ zu installieren, um einen Client-Zugriff zu
>ermöglichen, kann doch nicht ernst gemeint sein. Ein Postgres-Klient
>(sprich: sowohl PgAdmin3 als auch psql) ist natürlich schon lange auf dem
>Rechner installiert.

Es geht um die postgres-client-bibliotheken und header. Wenn die nur mit
Servern zu haben sind, dann ist das ein Problem der Paketierung von
postgres, nicht von Python oder Windows.

Mal abgesehen davon, dass ich deine Erregung nicht verstehe im Zeitalter
von Terabyte-Platten. Da liegt dann also ein nicht-laufender
Postgres-Server auf der Platte mit ein paar MB binares. Big Whoop.

>
>> Und alternativ auch noch
>> 
>>   https://github.com/mfenniak/pg8000
>> 
>> fuer eine pur-python-Implementierung des Netzwerkprotokolls von
>> postgres.
>
>Besten Dank! Das war die Lösung aller Probleme. Hier gibt es einen
>Verweis auf die Homepage des Projektes, die wiederum einige direkt
>benutzbare Downloads anbietet und mich vor allem auf die Idee brachte
>einfach mal ein
>
>    easy_install pg8000
>
>zu versuchen, was auf Anhieb funktionierte. Und auch die weitere
>Benutzung dieses Treiber funktioniert ohne Probleme.

Schoen, dass es so gut klappt.

>
>Datenbanktreiber (für jede Programmiersprache), die auf externen Fremd-
>Bibliotheken (.dll bzw. .so) aufbauen, waren schon immer eine Scheiß-Idee
>und sind nur in wenigen Fällen (z.B. für SQLite => es gibt keinen
>Datenbank-Server, der Treiber _ist_ die Datenbank  oder für DB2 => die
>Serververbindung ist nicht immer ein einfacher TCP/IP-Socket sondern kann
>auch auf einem heute fast unbekannten Großrechner-Netzwerk-Protokoll
>aufgesetzt sein) sinnvoll.

Low hanging fruit. Wenn die C-Bibliothek existent, ist es produktiver, sie
zu wrappen. Dann muss man das Binärprotokoll nicht analysieren, kann sich
auf die Testsuite der DB verlassen, fortgeschrittene Features wie
Binaer-Streams nutzen usw usf.

>
>Und warum gerade zwei der verbreitetsten Postgres-Treiber für Python
>unter Windows eine Postgres-_Server_-Installation voraussetzen, wird mir
>wohl immer ein Rätsel bleiben.

Das habe ich jetzt schon mehrfach erklärt, ich hoffe, das ist jetzt klarer
:)

Diez




Mehr Informationen über die Mailingliste python-de