[Python-Dev] Integrate BeautifulSoup into stdlib?

David Cournapeau cournape at gmail.com
Tue Mar 24 21:08:57 CET 2009

> This is only sortof true.  You can install rpms into a local directory
> without root privileges with a commandline switch.  But rpm/deb are
> optimized for system administrators so the documentation on doing this
> is not well done.  There can also be code issues with doing things this
> way but those issues can affect bundled apps as well. And finally, since
> rpm's primary use is installing systems, the toolset around it builds
> systems.  So it's a lot easier to build a private root filesystem than
> it is to cherrypick a single package.  It should be possible to create a
> tool that merges a system rpmdb and a user's local rpmdb using the
> existing API but I'm not aware of any applications built to do that yet.

Building private root kind of defeat the purpose :) Deploying linux
packages in a reliable way without requiring admin privileges is an
"interesting" experience. The tools just don't support this well - or
there exists some magical tools that I've never seen mention of.

> I won't argue for setuptools' implementation of multi-version.  It
> sucks.  But multi-version can be done well.  Sonames in C libraries are
> a simple system that does this better.

I would say simplistic instead of simple :) what works for C won't
necessarily work for python - and even in C, library versioning is not
used that often except for a few core libraries. Library versioning
works in C because C model is very simple. It already breaks for C++.
More high-level languages like C# already have a more complicated
scheme (GAC) - and my impression is that it did not work that well.
The SxS for dll on recent windows to handle multiple version is a
nightmare too in my (limited) experience.

> I'm confused -- if it will happen whatever tools are available, how does
> "good source control" solve the issue?  I'm saying that this is not an
> issue that can be solved by having good source control... it's a social
> issue that has to be solved by people learning to avoid bad practices.

I meant that whatever technology is available, bundling everything
will always be easier. And sometimes, given the time/resource
constraints, that's even the only realistic option. I could tell you
many stories about wasted hours related to some fortran libraries
which were hopelessly broken (missing symbols) on most distributions,
or ABI conflicts - for which bundling sometimes is the only path to
keep its sanity (short of giving up support for the platform). When
you need to solve the problem now because you want to demo things
tomorrow, not in 6 months, that's the only solution. It is not always
bad practice.

IMHO, one should focus on making it easier to avoid bundling
everything - robust and simple dependency scheme, adapting distutils
installation scheme to the various OS conventions, be it FHS, windows,
etc... But we can't and shouldn't prevent it totally, and tools are
already there to help minimizing the problems of bundling. For
multiple system-wide libraries, I have yet to encounter anything which
makes it somewhat reliable - it has only caused problems for me, and
not solved any single problem.



More information about the Python-Dev mailing list