[Python-Dev] Integrate BeautifulSoup into stdlib?

[David Cournapeau]

On Wed, Mar 25, 2009 at 2:20 AM, Tres Seaver <tseaver at palladion.com> wrote:

>
> Many of us using setuptools extensively tend to adopt an "isolated
> environment" strategy (e.g., pip, virtualenv, zc.buildout).  We don't
> install the packages used by different applications into shared
> directories at all.  Instead, each environment uses a restricted subset
> of packages known to work together.

Is that a working solution when you want to enable easy installation
on a large number of "customers" ? In those discussions, I often see
different solutions depending on the kind of projects people do. I
don't know anything about plone, but I can imagine the deployment
issues are quite different from the projects I am involved in (numpy
and co).

Everytime I tried to understand what buildout was about, I was not
even sure it could help for my own problems at all. It seems very
specific to web development - I may completely miss the point ?
virtualenv, pip, yolk, those are useful tools for development/testing,
but I don't see how they can help me to make the installation of a
numpy environment easier on many different kind of platforms.

>
>> If the problem is to get a recent enough version of the library, then
>> the library would better be installed "locally", for the application.
>> If it is too much a problem because the application depends on
>> billions of libraries which are 6 months old, the problem is to allow
>> such a dependency in the first place. What kind of nightmare would it
>> be if programs developed in C would required a C library which is 6
>> months old ? That's exactly what multiple-versions installations
>> inflict on us. That's great for testing, development. But for
>> deployment on end-user machines, the whole thing is a failure IMO.
>
> It is wildly successful, even on platforms such as Windows, when you
> abandon the notion that separate applications should be sharing the
> libaries they need.

Well, I may not have been clear: I meant that in my experience,
deploying something with several dependencies was easier with bundling
than with a mechanism ala setuptools with *system-wide* installation
of multiple versions of the same library. So I think we agree here:
depending on something stable (python stdlib + a few well known
things) system-wide is OK, for anything else, not sharing is easier
and more robust in the current state of things, at least when one
needs to stay cross platform.

Almost every deployment problem I got from people using my own
softwares was related to setuptools, and in particular the multiple
version thing. For end-users who know nothing about python package
mechanism, and do not care about it, that's really a PITA to debug,
and give bad mouth taste. The fact that those problems happen when my
software was not even *using* setuptools/etc... was a real deal
breaker for me, and I am strongly biased against setuptools ever
since.

>
> FHS is something which packagers / distributors care about:  I strongly
> doubt that the "end users" will ever notice, particularly for silliness
> like 'bin' vs. 'sbin', or architecture-specific vs. 'noarch' rules.

That's not silly, and that's a bit of a fallacy. Of course end users
do not care about the FHS in itself, but following the FHS enables
good integration in the system, which end users do care about. I like
finding my doc in /usr/share/doc whatever thing I install - as I am
sure every window user like to find his installed software in the
panel control.

>
> As a counter-example, I offer the current Plone installer[1], which lays
> down a bunch of egg-based packages in a cross-platform way (Windows,
> MacOSX, Linux, BSDs).  It uses zc.buildout, which makes
> configuration-driven (repeatable) installation of add-ons easy.

But zc.buildout is not a solution to deploy applications, right ? In
my understanding, it is a tool to deploy plone instances on
server/test machines, but that's quite a different problem from
installing "applications" for users who may not even know what python
is.

cheers,

David