Weitere Libraries in einem egg bündeln?
Hi, ich möchte meine Python-Bibliothek zusammen mit anderen in *einem* egg file verteilen. Es geht mir hierbei nicht darum, die anderen Bibliotheken zu forken, sondern um eine möglichst einfache Installation. Im Moment können Nutzer das egg einfach nehmen und in einen definierten Ordner legen. Anschließend funktioniert alles. Das möchte ich so beibehalten, selbst wenn ich externe Bibliotheken benutze. Ich könnte jetzt die Bibliotheken natürlich in meinen Namensraum übernehmen (z.B. felix.foo für die foo Bibliothek). Eigentlich würde ich die Bibliothek aber gerne so benutzen, als ob sie systemweit installiert wäre. Gibt es bei egg files eine Option, so dass ich weitere Bibliotheken unterhalb eines 'lib'-Ordners so behandeln kann, als ob sie normal installiert wären? (ich möchte die 3rd party Dinger nicht in meinem root liegen haben) fs
Felix Schwarz schrieb:
Hi,
ich möchte meine Python-Bibliothek zusammen mit anderen in *einem* egg file verteilen. Es geht mir hierbei nicht darum, die anderen Bibliotheken zu forken, sondern um eine möglichst einfache Installation.
Im Moment können Nutzer das egg einfach nehmen und in einen definierten Ordner legen. Anschließend funktioniert alles. Das möchte ich so beibehalten, selbst wenn ich externe Bibliotheken benutze.
Ich könnte jetzt die Bibliotheken natürlich in meinen Namensraum übernehmen (z.B. felix.foo für die foo Bibliothek). Eigentlich würde ich die Bibliothek aber gerne so benutzen, als ob sie systemweit installiert wäre.
Gibt es bei egg files eine Option, so dass ich weitere Bibliotheken unterhalb eines 'lib'-Ordners so behandeln kann, als ob sie normal installiert wären? (ich möchte die 3rd party Dinger nicht in meinem root liegen haben)
hallo felix, so richtig habe ich nicht verstanden was du willst ;) aber mal angerissen, du kannst externe packages benutzen wie du willst, diese würdes du dann als required mit in deiner setup.py angeben, damit sie automatisch nachgezogen werden, wenn du dein package installierst. Beispiel: install_requires=[ 'setuptools', # -*- Extra requirements: -*- 'z3c.tables', ], z3c.tables wird hier automatisch nachgezogen. Die packages könen im pypi oder auch lokal als development egg vorhanden sein. Was sind denn das für Bibliotheken die du einbinden möchtest, vorhandene Python Packages oder selbst gebaute von dir? Gruß Maik -- ======================================================================== Derstappen I T Consulting Tel: +49 ( 341 ) 600 13 0 31 Zope/E-Mail/Backup/Monitoring Mobil: +49 ( 178 ) 861 2 833 M a i k D e r s t a p p e n Fax: +49 ( 180 ) 5 021 121 90 56 H e r l o ß s o h n s t r 12 Email: maik.derstappen@derstappen-it.de 0 4 1 5 5 L e i p z i g Internet: http://www.derstappen-it.de ========================================================================
Am 20.03.2010 23:14, schrieb Maik Derstappen, Derstappen IT:
so richtig habe ich nicht verstanden was du willst ;)
Ich versuchs noch mal - so soll es aussehen: myegg | |- mylib (eigene Bibliothek) |- lib/foo (externe Bibliothek) Innerhalb von 'mylib' möchte ich einfach 'import foo' sagen können.
aber mal angerissen, du kannst externe packages benutzen wie du willst, diese würdes du dann als required mit in deiner setup.py angeben, damit sie automatisch nachgezogen werden, wenn du dein package installierst.
Kenne ich, nutze ich auch viel. Ist aber für meine Nutzer nicht wirklich hilfreich, weil die z.T. extrem untechnisch sind. Wie ich in der ersten Mail schrieb: "Im Moment können Nutzer das egg einfach nehmen und in einen definierten Ordner legen. Anschließend funktioniert alles. Das möchte ich so beibehalten, selbst wenn ich externe Bibliotheken benutze." Also im Prinzip ist die Frage, ob man setuptools/zipimport so modifizieren kann, dass ein Unterordner eines zips an sys.path angehängt werden kann. fs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wenn beide Module zusammengehören, dann verschmelze Sie zu einen Package aber versuch nicht hier ein Package in ein anderes reinzumischen. Das ist Package Frickelei. Wenn beide Module unabhängig sind, dann paketiere diese auch sauber unabhängig voneinander. Beide Pakete auf über den gleichen Kanal zu distributieren und zu installieren kann ja nicht das Problem sein - insb. wenn man unter Angabe eines dedizierten Index-Servers bei privater Distribution auch die Abhängigkeiten automatisch ohne weitere Interaktion des Benutzers installieren lassen kann. Sorry to say: aber es gibt bereit genug vergurkte Python-Module und Packages in der der freien Wildbahn. Füge bitte nicht noch weitere hinzu. Andreas Felix Schwarz wrote:
Am 20.03.2010 23:14, schrieb Maik Derstappen, Derstappen IT:
so richtig habe ich nicht verstanden was du willst ;)
Ich versuchs noch mal - so soll es aussehen: myegg | |- mylib (eigene Bibliothek) |- lib/foo (externe Bibliothek)
Innerhalb von 'mylib' möchte ich einfach 'import foo' sagen können.
aber mal angerissen, du kannst externe packages benutzen wie du willst, diese würdes du dann als required mit in deiner setup.py angeben, damit sie automatisch nachgezogen werden, wenn du dein package installierst.
Kenne ich, nutze ich auch viel. Ist aber für meine Nutzer nicht wirklich hilfreich, weil die z.T. extrem untechnisch sind.
Wie ich in der ersten Mail schrieb: "Im Moment können Nutzer das egg einfach nehmen und in einen definierten Ordner legen. Anschließend funktioniert alles. Das möchte ich so beibehalten, selbst wenn ich externe Bibliotheken benutze."
Also im Prinzip ist die Frage, ob man setuptools/zipimport so modifizieren kann, dass ein Unterordner eines zips an sys.path angehängt werden kann.
fs
------------------------------------------------------------------------
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
- -- ZOPYX Limited \ zopyx group Charlottenstr. 37/1 \ The full-service network for your D-72070 Tübingen \ Python, Zope and Plone projects www.zopyx.com, info@zopyx.com \ www.zopyxgroup.com - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkulzTgACgkQCJIWIbr9KYx54wCeMvZ7M25RPOIIP0eMGC4GSC9M k8gAoMWTd2Q16Sc1hki+kk8BRv63Y1KJ =GHF4 -----END PGP SIGNATURE-----
Am 21.03.2010 08:39, schrieb Andreas Jung:
Wenn beide Module zusammengehören, dann verschmelze Sie zu einen Package aber versuch nicht hier ein Package in ein anderes reinzumischen. Das ist Package Frickelei. Wenn beide Module unabhängig sind, dann paketiere diese auch sauber unabhängig voneinander.
Prinzipiell stimme ich dir zu. Ich möchte einzig und allein das Distributions-/Installationsproblem lösen. Im Code soll es keinen Unterschied machen, ob die externe Bibliothek im gleichen egg ist oder extern installiert - gerade weil ich an eine saubere Trennung zwischen libraries befürworte. Nur wäre es für bestimmte Endbenutzer wichtig, dass sie eben einfach eine einzige Datei haben, die sie irgendwo hinlegen. Im klassischen 'free software' Bereich ist das egal, im kommerziellen Umfeld kostet jeder extra Klick/jedes Kommando ganz real Euros. fs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Felix Schwarz wrote:
Am 21.03.2010 08:39, schrieb Andreas Jung:
Wenn beide Module zusammengehören, dann verschmelze Sie zu einen Package aber versuch nicht hier ein Package in ein anderes reinzumischen. Das ist Package Frickelei. Wenn beide Module unabhängig sind, dann paketiere diese auch sauber unabhängig voneinander.
Nur wäre es für bestimmte Endbenutzer wichtig, dass sie eben einfach eine einzige Datei haben, die sie irgendwo hinlegen. Im klassischen 'free software' Bereich ist das egal, im kommerziellen Umfeld kostet jeder extra Klick/jedes Kommando ganz real Euros.
Sorry, das ist eine ziemlich kranke Begründung. Würde ich die Aufwände die wir für das Fixen von kaputten Python Packages schon aufgewendet haben den entsprechenden Programmierern in Rechnung stellen, dann wäre ich um einiges reicher und mancher Python Frickler ruiniert. - -aj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkul6cAACgkQCJIWIbr9KYy9gwCghCPzTaA23WS0z25qG1FREGLb kdAAoOYq5ThIeOtyEbvXhhiYlLeC6rRb =KTW4 -----END PGP SIGNATURE-----
Am 20.03.2010 22:20, schrieb Felix Schwarz:
ich möchte meine Python-Bibliothek zusammen mit anderen in *einem* egg file verteilen. Es geht mir hierbei nicht darum, die anderen Bibliotheken zu forken, sondern um eine möglichst einfache Installation.
Ganz schlecht Idee! Zudem dem, was Andreas schon geschrieben hat: Wenn Du andere Packages in deins hineinpackst, bekommen die Benutzer ein massives Wartungsproblem. Es braucht nur ein elender Bug oder gar eine Sicherheitslücke in Package 'foo' auftreten. Die Benutzer wissen noch nicht einmal, dass sie betroffen sind, geschweige denn, dass sie eine neue Version von 'foo' einspielen könnten. Wenn Du dennoch eine "einfache" Installation möchtest, gibt es folgende einfach Lösungen: a) Wenn die Benutzer sowieso schon Python installiert haben: Zip-File mit allen benötigten Packages und ein installer.py. b) Unter Unix/Linux: Python ist in der Regel installiert :-) c) Windows: Alle Packages asl .msi liefern und mit NSIS oder Innosetup einen Installer bauen, der die der Reihe nach installiert. Aber bitte, bitte das Zip-File nicht auf pypi stellen. Danke. BTW: Solche Probleme haben viele Unternehmen, die Java-Programme einsetzen, die jeweils ihre eigenen JRE mitbringen. Da schlummern in Banken und Versicherungen Bomben mit veralteten und unsicheren JREs, die vor drei Jahren abgekpndigt und seit 2 Jahren tot sind. Ähnliches gilt für Python und für GTK unter Windows. Aber ich schweife ab ;-) -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de
Am 21.03.2010 10:48, schrieb Hartmut Goebel:
Wenn Du andere Packages in deins hineinpackst, bekommen die Benutzer ein massives Wartungsproblem. Es braucht nur ein elender Bug oder gar eine Sicherheitslücke in Package 'foo' auftreten. Die Benutzer wissen noch nicht einmal, dass sie betroffen sind, geschweige denn, dass sie eine neue Version von 'foo' einspielen könnten.
Ich bin u.a. auch Fedora-Packager. Mir sind die Probleme zur Genüge bekannt und ich stimme euch voll zu.
Aber bitte, bitte das Zip-File nicht auf pypi stellen. Danke.
Auf gar keinen Fall. Es geht hier um das Deployment für eine bekannte Nutzergruppe und nicht um das 'default egg' für pypi :-) Nun ja, dann werde ich wohl etwas in setuptools 'reinfassen' müssen... Und keine Angst: Jeder Benutzer kann ganz einfach die Dinge systemweit installieren und dann wird diese Installation benutzt. Es geht mir nur darum, den "Dummies" zu helfen, die vor jeder Kommandozeile zurückschrecken bzw. überhaupt keine eigene Expertise im Bereich Administration haben. Ich werde Experten sicherlich keine Steine in den Weg legen. fs
Am 21.03.2010 12:01, schrieb Felix Schwarz:
Und keine Angst: Jeder Benutzer kann ganz einfach die Dinge systemweit installieren und dann wird diese Installation benutzt. Es geht mir nur darum, den "Dummies" zu helfen, die vor jeder Kommandozeile zurückschrecken bzw. überhaupt keine eigene Expertise im Bereich Administration haben. Ich werde Experten sicherlich keine Steine in den Weg legen.
Und Du bist Dir sicher, dass solhe Leute überhaupt Anwendungen installieren können sollen?! Willst Du dann nicht eher doch einen Installer bauen? In einem anderen Posting sprichst Du davon, dass jede Mausklick Geld kostet. Was nun? Dummy-User oder professionelle Admins? Für den Dummy-User kostet die Installation erstmal nichts, denn das sind "eh da"-Kosten (falls es nicht privat ist). Die Kosten hier entstehen, weil der Dummy keinen Plan hat und hinterher ein Profi aufräumen muss. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de
Hi Felix, eventuell hilft dir pip (http://pypi.python.org/pypi/pip/0.6.3) weiter. Da kann man sogenannte 'Bundles' definieren. Ansonsten hoert sich deine Anforderung so an, dass du eigenlich deine lib und alle anderen in einen container packen willst, der irgendwohin entpackt wird, .pth file geschrieben, und voila, alles da :-) Ansonsten kann man bestimmt auch was mit buildout machen... Kurz und gut, so ganz automatisch wirst du's wohl nicht hinbekommen. Gruss, Stephan Felix Schwarz wrote:
Hi,
ich möchte meine Python-Bibliothek zusammen mit anderen in *einem* egg file verteilen. Es geht mir hierbei nicht darum, die anderen Bibliotheken zu forken, sondern um eine möglichst einfache Installation.
Im Moment können Nutzer das egg einfach nehmen und in einen definierten Ordner legen. Anschließend funktioniert alles. Das möchte ich so beibehalten, selbst wenn ich externe Bibliotheken benutze.
Ich könnte jetzt die Bibliotheken natürlich in meinen Namensraum übernehmen (z.B. felix.foo für die foo Bibliothek). Eigentlich würde ich die Bibliothek aber gerne so benutzen, als ob sie systemweit installiert wäre.
Gibt es bei egg files eine Option, so dass ich weitere Bibliotheken unterhalb eines 'lib'-Ordners so behandeln kann, als ob sie normal installiert wären? (ich möchte die 3rd party Dinger nicht in meinem root liegen haben)
fs
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (5)
-
Andreas Jung -
Felix Schwarz -
Hartmut Goebel -
Maik Derstappen, Derstappen IT -
Stephan Diehl