[Python-Dev] Integrate BeautifulSoup into stdlib?

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Cournapeau wrote:
> 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.

OK, but I'm still not convinced that the Plone installers don't fit this
case.  It's just that they also allow add-on installation afterward:
the "main" Plone application is installed via a GUI wizard (on Windows /
OSX).

>> 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.

Have you tried using the script you can generate from it?  E.g.,:

 >>> MY_ADDON_CODE = """\
 ...
 def after_install(options, home_dir):
     subprocess.call([join(home_dir, 'bin', 'easy_install'),
                                 'MyPackage'])
 """
 >>> from virtualenv import create_bootstrap_script
 >>> f = open('/tmp/myinstaller.py', 'w')
 >>> f.write(create_bootstrap_script(MY_ADDON_CODE)
 >>> f.close()

Users would then be able to run that script and get a virtualenv, with
your 'MyPackage' distribution already installed in it.

>> 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).

Hmm, if your package uses "pure" distutils facilities, then it should be
installable by setuptools as an egg without problems.  Why would your
users be trying to to '--multi-version' installs of your package?

>> 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.

Again:  I've *never* seen packages installed in multi-version fashion,
except in the very different mode (not in sys.path, nor in a directory
significant to site.py) used by zc.buildout.


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

iD8DBQFJyUmK+gerLs4ltQ4RAmL6AJ4pzQiVLeoHWPkJ4yi1nNX2d9svBACfXrEZ
wKDmINnLwkDzTmzhYoJQnP0=
=pTeA
-----END PGP SIGNATURE-----