[Python-Dev] Integrate BeautifulSoup into stdlib?

[Stephen J. Turnbull]

Chris Withers writes:

 > aptitude also won't help when:
 > - your customer is deploying onto managed machines running RHEL

True.

 > - debian has an outdated and/or broken version of your package.

True, but just as for the package system you are advocating, it's
quite easy to set up your apt to use third-party repositories of
Debian-style packages.  The question is whether those repositories
exist.  Introducing yet another, domain-specific package manager will
make it less likely that they do, and it will cause more work for
downstream distributors like Debian and RH.

 > The latter is a standard problem with Zope/Apache/Postgres in
 > debian and causes much gnashing of teeth by people trying to
 > support them. The Debian guys love buggering around with other
 > people's packaging, not caring that it makes supporting stuff so
 > much harder.

Well, I can't speak for the Debian Zope/Apache/Postgres maintainers,
but I assure you the Emacs maintainers do care.  But their hands are
full trying to implement what you keep proposing as a solution, viz.,
a "batteries-included distribution built on top of a package system".

If you don't like Debian, fine, as an upstream vendor, I don't either.
But an awful lot of my users *do* like[1] Debian (or Ubuntu or another
Debian-derived distro).  I see no alternative to cooperating with them
(though I sometimes complain loudly throughout the process<wink>).

If you want to see where the kind of thing you propose can lead, take
a look at the Debian Emacs Policy document, which is designed to deal
with one fork that takes the batteries-included approach, and another
that has gone a long way in the direction of unbundling packages.
Note that while Python doesn't have a political fork of the kind that
Emacs does, it *does* have multiple blessed technical forks, and your
suggestion involves the creation of yet more forks (ie, the
distributions with bundled packages, versus those without).  Whether
the technical differences among Python implementations and packaging
strategies will lead to the kind of issues that form the background of
the Debian Emacs Policy, I don't know.  But you don't know either.

 > A cross-plaftorm, platform agnostic, python-centric package
 > management system is what's needed.

That's what you (think you[2]) need, but that statement rudely ignores
the stated requirements of many other users.  What you are doing here
is divisive, not unifying.

 > Setuptools comes close, but I wonder if it's impossible to get it
 > to do the last bits of what's needed (uninstall being the big one,
 > and knowing what version of what package you have installed!)

Why wonder, when you can try an implementation and report the results?

I guess you mean you hope somebody else will do the work (not only of
development, but of maintaining the package repository).  Well,
"somebody else" has *already* done "the work", but unfortunately<wink>
they defined "the work" in their own way.  The result is the
batteries-included stdlib.


Footnotes: 
[1]  For values of "like" including but not limited to "see no
superior alternative to".

[2]  If "your users" include Debian and RHEL users, you may find that
they are not so happy with yet more PMS.