[Python-Dev] Integrate BeautifulSoup into stdlib?

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Cournapeau wrote:

> There already is a bit of a DLL hell in python. The whole idea to
> solve the dependency problems by installing multiple version of the
> same software is fundamentally flawed, it just does not work for
> general deployment on multiple machines. Many systems outside python,
> with more resource, have tried - and failed. By enabling a general,
> system-wide installation of multiple version of the same package,
> setuptools has made the situation worse. I am quite puzzled than many
> people don't realize this fundamental issue, it is a simple
> combinatory problem.

Many of us using setuptools extensively tend to adopt an "isolated
environment" strategy (e.g., pip, virtualenv, zc.buildout).  We don't
install the packages used by different applications into shared
directories at all.  Instead, each environment uses a restricted subset
of packages known to work together.

> If the problem is to get a recent enough version of the library, then
> the library would better be installed "locally", for the application.
> If it is too much a problem because the application depends on
> billions of libraries which are 6 months old, the problem is to allow
> such a dependency in the first place. What kind of nightmare would it
> be if programs developed in C would required a C library which is 6
> months old ? That's exactly what multiple-versions installations
> inflict on us. That's great for testing, development. But for
> deployment on end-user machines, the whole thing is a failure IMO.

It is wildly successful, even on platforms such as Windows, when you
abandon the notion that separate applications should be sharing the
libaries they need.

>> I am afraid that distutils, and
>> setuptools, are not really the answer to the problem, since while they
>> may (as intended) guarantee that Python applications can be installed
>> uniformly across different platforms they also more or less guarantee
>> that Python applications are installed differently from all other
>> applications on the platform.
> 
> I think they should be part of the solution, in the sense that they
> should allow easier packaging for the different platforms (linux,
> windows, mac os x and so on). For now, they make things much harder
> than they should (difficult to follow the FHS, etc...).

FHS is something which packagers / distributors care about:  I strongly
doubt that the "end users" will ever notice, particularly for silliness
like 'bin' vs. 'sbin', or architecture-specific vs. 'noarch' rules.

> But otherwise,
> I agree. Python applications which care about non-savy users should be
> distributed as .dmg, .exe, .rpm, .deb. There will always be some work
> to do that correctly: there is no way to provide a general, automatic
> environment to build installers which provide a good experience on all
> platforms. AFAIK, It does not even exist in the commercial landscape,
> so I see little chance to see this in the python ecosystem.

As a counter-example, I offer the current Plone installer[1], which lays
down a bunch of egg-based packages in a cross-platform way (Windows,
MacOSX, Linux, BSDs).  It uses zc.buildout, which makes
configuration-driven (repeatable) installation of add-ons easy.

[1] http://plone.org/products/plone


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJyRZH+gerLs4ltQ4RAu3qAKDXhkY73S2htl6Ytz+ZPVyRgYSHLACdGo+N
XNMrpg7ue0SX3ODgiOjHTmg=
=Rk1D
-----END PGP SIGNATURE-----