Windows: Postgres-Zugriff ohne Server-Installation

[Volker Böhm]

Hallo,
nach einigen Stunden Recherche stehe ich jetzt kurz vor der Detonation:

Ist es in Python unter Windows möglich, einen Zugriff auf eine Postgres-
DB zu installieren, ohne einen kompletten Postgres-Server zu
installieren? Und wenn ja wie?

Bisher habe ich psycopg2 und PyGreSQL (jeweils mit easy_install)
ausprobiert. Und bei beiden die gleiche Fehlermeldung:
'pg_config tool not available' bzw. 'pg_config executable not found'.

Und alle (gefühlte 8743 Stellen im Web) reden immer davon, man solle
Postgres installieren. Ich habe genug installierte Postgres-Server; aber
was hat sowas auf einem Windows-Notebook zu suchen?

Ich sehe ja ein, dass - im Gegensatz zu anderen Programmiersprachen (wie
z.B. Java) - in Python scheint's eine _externe_ Bibliothek benötigt wird,
um einen Zugriff auf einen Postgres-Server zu ermöglichen. Aber es kann
doch nicht wahr sein, dass man für so eine popelige DLL - oder was auch
immer dieses ominöse pg_config.??? auch ist - einem armen Windows-Rechner
mit einem ganzen Postgres-Server zumüllen muss.

Ach ja: Das Frust-Objekt ist ein Notebook mit Windows 7 und cygwin.

Ich hoffe, ihr könnt mir irgendwie weiterhelfen, bevor das Ding in der
Elbe landet.

mfg Volker

PS: Unter einem beliebigen Linux installiert man übrigens einfach das
Paket 'python-psycopg2' und der Drops ist gelutscht. Warum muss alles
unter Windows eigentlich immer so kompliziert sein?

--
Volker Böhm Tel.: +49 4141 981152 www.vboehm.de
Voßkuhl 5 Fax: +49 4141 981154
D-21682 Stade mailto:vol...@vboehm.de

[Diez B. Roggisch]

nach einigen Stunden Recherche stehe ich jetzt kurz vor der Detonation:

Ist es in Python unter Windows möglich, einen Zugriff auf eine Postgres-
DB zu installieren, ohne einen kompletten Postgres-Server zu
installieren? Und wenn ja wie?

Bisher habe ich psycopg2 und PyGreSQL (jeweils mit easy_install)
ausprobiert. Und bei beiden die gleiche Fehlermeldung:
'pg_config tool not available' bzw. 'pg_config executable not found'.

Und alle (gefühlte 8743 Stellen im Web) reden immer davon, man solle
Postgres installieren. Ich habe genug installierte Postgres-Server; aber
was hat sowas auf einem Windows-Notebook zu suchen?

Ich sehe ja ein, dass - im Gegensatz zu anderen Programmiersprachen (wie
z.B. Java) - in Python scheint's eine _externe_ Bibliothek benötigt wird,
um einen Zugriff auf einen Postgres-Server zu ermöglichen. Aber es kann
doch nicht wahr sein, dass man für so eine popelige DLL - oder was auch
immer dieses ominöse pg_config.??? auch ist - einem armen Windows-Rechner
mit einem ganzen Postgres-Server zumüllen muss.

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/

was durch googeln von "psycopg2 windows installer" zustande kommt - das musst du schon selber wissen.

Und alternativ auch noch

  https://github.com/mfenniak/pg8000

fuer eine pur-python-Implementierung des Netzwerkprotokolls von postgres.

Ach ja: Das Frust-Objekt ist ein Notebook mit Windows 7 und cygwin.

Ich hoffe, ihr könnt mir irgendwie weiterhelfen, bevor das Ding in der
Elbe landet.

mfg  Volker

PS: Unter einem beliebigen Linux installiert man übrigens einfach das
Paket 'python-psycopg2' und der Drops ist gelutscht. Warum muss alles
unter Windows eigentlich immer so kompliziert sein?

Hauptsaechlich weil es keine freien Compiler von MS gibt. Bzw. nur eingeschraenkt, in bestimmten Versionen usw.

Diez

[Volker Böhm]

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). Und probiert hatte ich die Installation damit auch aber es kam
nur eine schwachsinnige Meldung, in der Registry sei kein Python
eingetragen.

> was durch googeln von "psycopg2 windows installer" zustande kommt - das
> musst du schon selber wissen.

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.

> 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.

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.

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.

Besten Dank für die schnelle Hilfe.

mfg Volker

[Diez Roggisch]

On 4/11/13 11:46 AM, "Volker Böhm" <vol...@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

[Thomas Orgelmacher]

Am 11.04.2013 11:46, schrieb Volker Böhm:

> 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.

Weil sie gegen die, auf dem System vorhandene, libpq.so (keine Ahnung
wie die unter Windows heißt) linken. Und das ist die Bibliothek mit
den Postgres Client-Funktionen.
Steht z.B. auf der Homepage bei PyGreSQL: "It embeds the PostgreSQL
query library to allow easy use of the powerful PostgreSQL features
from a Python script".

Wie viele vorkompilierte Bibliotheken sollen die Module denn mitbringen
(32/64Bit, Postgres-Version, etc.)? So wie das gemacht ist, ist das
schon sinnvoll.

Und für alles weitere gibt es ja pg800... py-postgresql (den ich idR.
verwende) ist übrigens auch pure-python.

Gruß,

Orgel

--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.