[Python-Dev] Integrate BeautifulSoup into stdlib?

[Toshio Kuratomi]

David Cournapeau wrote:
> 2009/3/24 Toshio Kuratomi <a.badger at gmail.com>:
>> Steve Holden wrote:
>>
>>> Seems to me that while all this is fine for developers and Python users
>>> it's completely unsatisfactory for people who just want to use Python
>>> applications. For them it's much easier if each application comes with
>>> all dependencies including the interpreter.
>>>
>>> This may seem wasteful, but it removes many of the version compatibility
>>> issues that otherwise bog things down.
>>>
>> The upfront cost of bundling is lower but the maintenance cost is
>> higher.  For instance, OS vendors have developed many ways of being
>> notified of and dealing with security issues.  If there's a security
>> issue with gtkmozdev and the python bindings to it have to be
>> recompiled, OS vendors will be alerted to it and have the opportunity to
>> release updates on zero day, the day that the security announcement goes
>> out.
> 
> I don't think bundling should be compared to depending on the system
> libraries, but as a lesser evil compared to requiring multiple,
> system-wide installed libraries.
> 
Well.. I'm not so sure it's even a win there.  If the libraries are
installed system-wide, at least the consumer of the application knows:

1) Where to find all the libraries to audit the versions when a security
issue is announced.
2) That the library is unforked from upstream.
3) That all the consumers of the library version have a central location
to collaborate on announcing fixes to the library.

With my distribution packager hat on, I can say I dislike both multiple
versions and bundling but I definitely dislike bundling more.

>> 3) Over time, bundled libraries tend to become forked versions.  And
>> worse, privately forked versions.  If three python apps all use slightly
>> different older versions of libfoo-python and have backported fixes,
>> added new features, etc it is a nightmare for a system administrator or
>> packager to get them running with a single version from the system
>> library or forward port them.  And because they're private forks the
>> developers lose out on collaborating on security, bugfixes, etc because
>> they are doing their work in isolation from the other forks.
> 
> This is a purely technical problem, and can be handled by good source
> control systems, no ?
> 
No.  This is a social problem.  Good source control only helps if I am
tracking upstream's trunk so I'm aware of the direction that their
changes are headed.  But there's a wide range of reasons that
application developers that bundle libraries don't do that:

1) not enough time in a day.  I'm working full-time on making my
application better.  Plus I have to update all these bundled libraries
from time to time, testing that the updates don't break anything.  I
don't have time to track trunk for all these libraries -- I barely have
time to track releases.

2) My release schedule doesn't mesh with all of the upstream libraries
I'm bundling.  When I want to release Foo-1.0, I want to have some
assurance that the libraries I'm bundling with will do the right thing.
   Since releases see more testing than trunk, tracking trunk for twenty
bundled libraries is a lot less attractive than tracking release branches.

3) This doesn't help with the fact that my bundled version of the
library and your bundled version of the library are being developed in
isolation from each other.  This needs central coordination which people
who believe bundling libraries are very unlikely to pursue.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090324/a68c4032/attachment.pgp>