[Python-Dev] Integrate BeautifulSoup into stdlib?

[Tres Seaver]

-----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          tseaver at 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-----