[Python-Dev] Integrate BeautifulSoup into stdlib?

David Cournapeau cournape at gmail.com
Tue Mar 24 18:23:19 CET 2009

On Wed, Mar 25, 2009 at 1:45 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> 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.

Yes, those are problems, but installing multi libraries have a lot of
problems too:
 - quickly, by enabling multiple version installed, people become very
sloppy to handle versions of the dependencies, and this increases a
lot the number of libraries installed - so the advantages above for
system-wide installation  becomes intractable quite quickly
 - bundling also supports a real user-case which cannot be solved by
rpm/deb AFAIK: installation without administration privileges.
 - multi-version installation give very fragile systems. That's
actually my number one complain in python: setuptools has caused me
numerous headache, and I got many bug reports because you often do not
know why one version was loaded instead of another one.

So I am not so convinced multiple-version is better than bundling - I
can see how it sometimes can be, but I am not sure those are that
important in practice.

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

Yes, but in that case, there is nothing you can do. Putting everything
in one project is always easier than splitting into modules, coding
and deployment-wise. That's just one side of the speed of development
vs maintenance issue IMHO.

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

As above, I think that in that case, it will happen whatever tools are
available, so it is not a case worth being pursued.



More information about the Python-Dev mailing list