[Python-de] setuptools to the rescue?

Diez B. Roggisch deets at web.de
Fre Jan 13 12:12:28 CET 2006


> [ ] Du hast schon mal Python-Erweiterungen in C geschrieben.

Ja, in C und auch in pyrex - und beides einfach mittels distutils compilieren 
lassen, ganz ohne make zu benoetigen.

> [ ] Du hast Make verstanden

Fuer sowas wie unten - ganz sicher. 

> [ ] Du hast Erfahrungen mit Autoconf

Begrenzt, aber auch das.

> Die Existenz von Autoconf beruht nicht auf Beschränkungen bei
> make. Autoconf wird verwendet, um Makefiles zu konfigurieren in
> Fällen, wo dies manuell nicht so einfach wäre bzw. um dem User die
> Installation zu vereinfachen und auf evtl. noch fehlende Software
> hinzuweisen. Das hat aber mit der Funktionalität von make nichts
> zu tun.

Du unterschlaegst hier das ich automake/autoconf geschrieben habe. Nicht 
autoconf alleine. Aus der automake info:

"""Automake is a tool for automatically generating `Makefile.in's from
 files called `Makefile.am'.  Each `Makefile.am' is basically a series
 of `make' macro definitions (with rules being thrown in occasionally).
 The generated `Makefile.in's are compliant with the GNU Makefile
 standards.
 
    The GNU Makefile Standards Document ( Makefile Conventions
 (standards)Makefile Conventions.)  is long, complicated, and subject to
 change.  The goal of Automake is to remove the burden of Makefile
 maintenance from the back of the individual GNU maintainer (and put it
 on the back of the Automake maintainer).
"""

Auch wenn sich das auf GNU bezieht: ich kenne kaum ein komplexeres Projekt das 
_nicht_ automake/autoconf verwendet. Was IMHO dafuer spricht, das eine Menge 
Leute lieber nicht komplexe Makefiles schreiben. Was nicht heisst das das 
gelegentlich passiern kann/muss. Aber im Kontext von Python - denke nicht. 

> Hier ging es um Abhängigkeiten wie z.B. "Erzeuge mir die Tabelle
> X, damit sie anschließend mit installert werden kann". Wenn die
> Tabelle erst exisiert, ist ihre Installation mit distutils
> trivial, aber um sie *vor* install zu erzeugen, erfordert es
> erhebliche und riskante Modifikationen am setup.py, da distutils
> selbst diese Funktionalität leider nicht mitbringt.

Das ist natuerlich Ansichtssache - aber ehrlich gesagt: eine richtige Sprache 
zur Verfuegung zu haben ist mir lieber als eine so sehr domainspezifische wie 
Make, vor allem weil sie auch noch (verhaeltnismaessig) kryptisch ist.  

Ich habe jetzt kein konkretes Make-Beispiel zur Hand, aber auf Arbeit (Java) 
verwenden wir natuerlich ant. Und da ist es mehr als einmal vorgekommen, das 
ich mittels bsf beanshell oder jython eingebunden habe, wenn komplexere 
Abhaengigkeiten ins Spiel kamen. 

> Warum nicht? Ich habe gerade ein Paket übersetzt, welches GTK+
> verwendet. Ich hatte instinktiv nach einem configure-Skript
> gesucht - Fehlanzeige. Also "make" und voila! Dann "make install"
> und gut ist. Wäre GTK+ nicht vorhanden gewesen, hätte ich
> natürlich in die Röhre geschaut. Mit einem .deb oder .rpm aber
> evtl. ebenfalls.

Ich sage nicht das es sowas nicht gibt - aber das Verhaeltnis von Paktet & 
configure-installierten Paketen zu (alleine!) make-basierten ist doch 
_deutlich_ richtung der ersteren beiden verschoben (selbst wenn man mal die 
debs weglaesst und nur configure und make vergleicht)

Mag natuerlich sein das das alles Warmduscher sind, die kein Make koennen :)

> Ein Makefile mit
>
>     install:
> 	python setup.py install
>
> ist noch einfacher.

Genausoeinfach wie ein

setup.sh

mit 

#!/bin/sh
python setup.py install

drin... _das_ kann ja kaum ein Argument fuer make sein :)

> Falls der Python-Code unter Windows läuft. ;-) Und sobald
> C-Erweiterungen im Spiel sind, ist das leider oft auch nicht mehr
> so einfach.

Man kann zwar davon ausgehen das unter Windows auch make vorhanden ist, wenn 
man C/C++ compilieren kann auf der Maschine - aber auch dann waere distutils 
zur compilation moeglich, oder? Gebe zu, das ich das selber noch nie probiert 
habe - aber ich denke mal das Plattformagnostizitaet das Ziel der distutils 
war (soweit moeglich).

MfG Diez