[python-users] Kompilierte C-Extension in ein Egg verpacken

[Andi Albrecht]

2012/12/5 M.-A. Lemburg <mal at egenix.com>:
> On 05.12.2012 21:38, Andi Albrecht wrote:
>> 2012/12/5 M.-A. Lemburg <mal at egenix.com>:
>>> On 05.12.2012 16:19, Andi Albrecht wrote:
>>>> Hallo zusammen,
>>>>
>>>> ich bin gerade ein bißchen ratlos.... Ich versuche, eine kompilierte
>>>> C-Extension in ein Paket zu verpacken, damit ich sie via pip
>>>> installieren kann.
>>>>
>>>> Bisher bin ich aber noch auf keinen vernünftigen Ansatz gestoßen, wie
>>>> ich mir da Pakete für die unterschiedlichen Platformen basteln kann.
>>>> Ich hatte gehofft, eine einfache setup.py schreiben zu können, der ich
>>>> irgendwie (<-- da scheitere ich) sagen kann: Das ist die *.so-Datei,
>>>> um dann mit "python setup.py bdist_egg --plat_name=platform" ein egg
>>>> zu erzeugen.
>>>>
>>>> Das einzige, was bisher funktioniert hat, war ein Dummy-Modul zu bauen
>>>> und die so-Datei als package_data mit zu paketieren:
>>>>
>>>> mymodule/
>>>>   __init__,py  (from mymodule import *)
>>>>   mymodule.so
>>>>
>>>> Das fühlt sich aber komisch an. Aber vielleicht bin ich auch nur gerade blind.
>>>>
>>>> Hat jemand sowas schonmal gemacht oder kennt jemand einen einfachen
>>>> Weg, eine vorkompilierte C-Extension zu paketieren?
>>>
>>> Normalerweise muß man distutils die C-Extension kompilieren lassen,
>>> damit die .so Datei auch im Paket landet.
>>>
>>> Falls das nicht geht, kann man aber auch per data_files die
>>> Dateien mitliefern:
>>>
>>> http://docs.python.org/2.7/distutils/setupscript.html#installing-additional-files
>>
>> Das Problem, dass ich mit data_files habe, ist, dass die so-Datei dann
>> erstmal nicht im PYTHONPATH landet. pkg_data kann ich in diesem Fall
>> auch nicht verwenden, da ich gar kein Package habe. Ich habe lediglich
>> eine einzige so-Datei (ein Python-Modul in C) und kann es leider auch
>> nicht selbst kompilieren, da es ein proprietäres Modul ist, dass ich
>> nur kompiliert erhalte.
>
> Dann nimm einfach die von Dir oben aufgeführte Variante mit
> einem Wrapper-Package.
>
> Das hat auch gleich noch ein paar andere Vorteile: Du kannst dann
> z.B. Funktionen ergänzen, den Import der C-Extension überprüfen und
> eine sinnvolle Fehlermeldung ausgeben, Logging des Imports
> hinzufügen, etc.
>
> Wir machen das bei den mx-Extensions schon seit vielen Jahren so,
> u.a. um zwischen Pure-Python- und C-Implementierungen bei Bedarf
> zu wechseln.
>
> PS: Wichtig ist, daß Du auch die Symbole mit Unterstrich importierst,
> z.B. __version__. Die kommen nämlich beim "... import *" nicht mit.

Danke! Das ist ein guter Tipp! Die hätte ich sicherlich vergessen :)

Ich denke, ich werde auch die Variante mit dem Wrapper-Script nehmen.
Das scheint mir letztlich die sicherste Lösung zu sein und du hast
natürlich völlig recht, dass ich mir damit auch noch zusätzliche
Möglichkeiten eröffne.

Beste Grüße,

Andi

>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Dec 05 2012)
>>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
> 2012-12-05: Released eGenix pyOpenSSL 0.13 ...    http://egenix.com/go37
> 2012-11-28: Released eGenix mx Base 3.2.5 ...     http://egenix.com/go36
> 2013-01-22: Python Meeting Duesseldorf ...                 48 days to go
>
> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/