[Python-Dev] Integrate BeautifulSoup into stdlib?

[Steve Holden]

Stephen J. Turnbull wrote:
> 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.
> 
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.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
Holden Web LLC                 http://www.holdenweb.com/
Want to know? Come to PyCon - soon! http://us.pycon.org/