buildout and distribution packaging
Hi all More and more python projects are "switching" to buildout. The one I face directly is Plone. I also administer servers and really love using their package management tools: If I use a Fedora (resp. Debian, Gentoo,...), I insist using yum/rpm (resp. apt/dpkgn, emerge,...) to install a software, and if the software needs some tunning, I act on the source package, then compile+install my tuned package. The question is to know wether the current "fashion" to switch to buildout will make the distribution packager work easier or harder. Taking the example of Perl and CPAN, it seems there is no nig problem, as well as there seems to be (in Debian at least) a specific tool to package Perl modules. Do you thing it will evolve that way for Python "buildouted" applications? Thank you. -- Chef de projet chez Vectoris Phone: +261 33 11 207 36 System: xUbuntu 8.10 with almost all from package install http://www.google.com/search?q=mihamina+rakotomandimby
On Thu, Apr 30, 2009 at 8:18 AM, Mihamina Rakotomandimby (R12y)
Hi all More and more python projects are "switching" to buildout. The one I face directly is Plone.
I also administer servers and really love using their package management tools: If I use a Fedora (resp. Debian, Gentoo,...), I insist using yum/rpm (resp. apt/dpkgn, emerge,...) to install a software, and if the software needs some tunning, I act on the source package, then compile+install my tuned package.
The question is to know wether the current "fashion" to switch to buildout will make the distribution packager work easier or harder.
A whole lot easier if your packager agrees that you are delivering an *application* composed of code, and not a list of packages. You can build a big RPM out of your buildout and provide it, or a .deb, with the right spec file so your various files are placed in the right place in the system tree. The fact that this application might have a package present elsewhere on your system, maybe another version, is unavoidable today and your packager might say that it's a security whole, and that it makes it harder for him to upgrade your app in case a package must be updated. But your application *has* to be a black box and you have to provide upgrades yourself. That said imho, one day, Python will evolve and provide multi-version support, and a feature for an application to pick the versions its needs. It's just too fuzzy and too controversial right now. Tarek -- Tarek Ziadé | http://ziade.org
On Thu, 30 Apr 2009 09:16:15 +0200, Tarek Ziadé
The fact that this application might have a package present elsewhere on your system, maybe another version, is unavoidable today and your packager might say that it's a security whole, and that it makes it harder for him to upgrade your app in case a package must be updated.
...
That said imho, one day, Python will evolve and provide multi-version support, and a feature for an application to pick the versions its needs. It's just too fuzzy and too controversial right now.
Hi Tarek, I have actually been debugging a lot of the old packaging code within python and I feel like I am slowly coming to understand it.
From what I understand of the code, multiple versions seem to be inherently ok, it all just depends on the order of the python-path code.
So if a package is sitting right in the application directory, it will get picked up first. And can be used. Provided the python-path points there... Furthermore, it seems that the .PTH files are really the key to the whole packaging system. They are all loaded in site.py (really old code) and they tell the underlying interpretor where to look for any of the packages that it needs. I can see where you are trying to drive things... and it makes sense... David
participants (3)
-
David Lyon -
Mihamina Rakotomandimby (R12y) -
Tarek Ziadé