On Sat, Mar 22, 2008 at 01:46:42PM +0000, Paul Moore wrote: > All this talk of "playing nicely with the system packager" seems to > imply that people are designing a second solution, and trying to > manage the interaction, rather than deciding on *one* solution (which > by definition has no interaction to worry about). > > It's reasonable to have multiple solutions for multiple Python > installations (system packager for the system python, python packager > for a local install, for example) but that's a different matter.
My server runs stable version of Debian, etch currently. It has python installed and most of the modules I need. However not all possible python modules are packaged but I as the local admin might decide a certain module -say pyprocessing- is really required for us and stable enough to use. I now need to install this locally. What I don't want in install an entire new python and hunt *all* modules and then make sure that the correct applications on my server use the correct python. > Oh, and application installation is (should be) completely different. > On Windows, applications should probably be bundled with their own > Python interpreter, a la py2exe. On Unix/Linux, I don't know what the > standard is, so I'd have to defer to others. An application packaged by the system (Debian in my case) will need to use the system modules. For the same reason we invented shared libraries instead of static libraries. When I have to install an application as local admin then I try to run it with the system python, using as many system modules as possible. If that's not possible (e.g. I need a sandbox) I'll often seriously reconsider installing that application. As a user I have no problems with trying out an app in virualenv or something like it. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
