[Python-Dev] Integrate BeautifulSoup into stdlib?

[David Cournapeau]

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

>
>> 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 ?
>
> I think so:  it is largely a way to get repeatable / scripted deployment
> of software to disk.  It uses setuptools to install Python package
> distributions, but also can use other means (e.g, configure-make-make
> install to install a C library such as libxml2).  The end result is a
> self-contained directory tree:
>
> - - Scripts in the 'bin' directory are configured to have the specific
>  Python pacakges (and versions) they require on the PYTHONPATH.
>
> - - By convention, released package distributions are installed into the
>  'eggs' subdirectory', which is *not* on the PYTHONPATH, nor is it a
>  'site' directory for Python.
>
> - - Other bits are typically in their own subdirectories, often under
>  'parts'.

Ok - but I don't think it helps much, see below.


> When not doing Plone / Zope-specific work (where zc.buildout is a de
> facto standard), I use 'virtualenv' to create isolated environments into
> which I install the libraries for a given application.  If your
> application ships as Python package distributions, then documenting the
> use of 'virtualenv' as a "supported" way to install it might reduce your
> support burden.

I now realize why we don't understand each other - in my case, the one
doing the installation is the user, who cannot be assumed to know much
about python.q11 That's what I mean by "application deployment vs
webapp deployment". Ideally, the user has to enter one command/click
one button, and he can use the application - he may not even be a
programmer (I deploy things based on numpy/scipy for scientific
people, who often have little patience for things which take more than
1 minute to set up software-wise).

That's the user case I am mostly interested in - and I think it is
quite general, and quite different from plone deployment kind of
things.

>
> You can think of zc.buildout or the virtualenv-based script as a form of
> bundling, which bootstraps from another already-installed Python, but
> remains isolated from anything in its 'site-packages'.

Yes, I know what virtualenv is, I use it sometimes - but it is
definitely too complicated for the people I want to distribute my
software to.

>
> I never even use that switch manually.  zc.buildout does, but that is
> because it wants to control the PYTHONPATH by generating the script
> code:  it doesn't ask users to tweak that.

Well, that's the thing: neither do I :) but if my software is a
dependency of another software, then I am bothered for problems with
software which are not used at all by my own package (because
setuptools makes an egg of my software automatically, screw things up,
and I am the one blamed for it).

>
> I don't know why anybody who was not writing a packaging tool, or
> packaging a library for something like .deb / .rpm, would even use the
> multi-version option for setuptools:  I don't see any sane way to
> install conflicting requirements into a shared 'site-packages'.

But that's the problem: it often happens *even if you don't use
setuptools yourself*. I would not be surprised if that's one reason
why so many people have a seemingly unfair bias against setuptools.
That's certainly the reason in my case.

cheers,

David