[Python-Dev] Integrate BeautifulSoup into stdlib?
cournape at gmail.com
Tue Mar 24 19:53:58 CET 2009
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
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
> 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
> 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.
More information about the Python-Dev