-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 R. David Murray wrote: > On Tue, 24 Mar 2009 at 07:53, Steve Holden wrote: >> I don't claim to have all the answers, but distutils and setuptools are >> for the savvy users - people who build distros and those who maintain >> their own systems independent of their distribution's packaging >> standard. As time goes by, however, and the Lunix installed base >> continues to grow, the majority of users will expect to rely on the >> standard installation mechanisms of their distribution, and that will >> never be setuptools or distutils.
I'll note that such users are mostly going to be installing desktop applications, which make a good case for the "batteries included" story, but one which ignores the "system" Python altogether, and bundles the interpreter. I think that building such a self-contained bundle would be eased by a strong story for managing out-of-core distributions. > +1. > > Or any other Python-only package manager. > > And that goes at least double for Windows :) I just did an install for a customer yesterday (actually, the customer did it, with me as "air traffic controller"), which started from the current Plone Windows installer, and then used the zc.buildout machinery shipped with Plone to add on the extra distributions (seven or so "community-maintained", plus one containing custom code). The buildout was driven from a text-based config file I supplied to the customer, which I developed and tested first on Linux. This method was *way* less painful and error-prone than downloading and running eight separate installers, *and* it ensured repeatability, because the extra distributions were all installed from a PyPI-style index I set up for the customer: I can recreate the environment at will (well, all the bits on disk under the main installation directory). If I need to fix one of the distributions which make up the application, ar add a new one, I will roll a new 'sdist' for it (no C extensions in play), upload it to the index, rebuild the metadata, and tell the customer to re-run the 'buildout.exe'. > I am (among other things) a software developer, and I am quite capable of > maintaining my own python installation outside the system one, and do so > for testing and development. But for anything else, I rely on the system > package manager to install my Python packages. If the extension hasn't > been packaged for my distribution, I typically will either not use it, > or I will install it somewhere other than the system default location. At which point you can benefit from the distributions-with-dependencies- in-an-index format provided, with varying levels of success, by setuptools today. I think the confusion-in-terms here may be that many Python developers don't use a large number of out-of-core distributions, and thus are mostly OK with managing the few they do use as part of their application: the rest they get from a "batteries include" Python. Mostly that is a reasonable choice, although I note that the Python 2.5 releases before 2.5.2 broke applicatinos using the tarfile module, and the 2.6 release broke applications using asyncore / asynchat: if those packages were shipped outside the stdlib, I could have fixed the breakage by updating them separately. Those of us who do need to deploy applications with larger dependency sets need tools which make it possible to do the deployments repeatably. The "use .deb / .rpm / Windows installer" answer just moves the effort around (and adds to it, in my experience), because in that world I end up running the equivalent of a PyPI index anyway: I can't rely on an upstream distro to package the correct versions for me, or to avoid breaking my application by the packaging choices they make. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJyRPu+gerLs4ltQ4RAjgPAKDB12YNxmAJX7VFN9WGvMR3H8KPHgCgt0NN vCKUCTkVcxjP09/LQVBP8G4= =2qbi -----END PGP SIGNATURE----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com