On 27 Aug, 15:27, "Diez B. Roggisch" <de...@nospam.web.de> wrote: > > You mean it's the problem of the python packaging that it can't deal with > RPMs, debs, tgzs, OSX bundles, MSIs and > <put-in-the-next-big-packaging-thing-here>?
No, it's the problem of the Pythonic packaging brigade that package retrieval, building and installing is combined into one unsatisfactory whole. Certainly, it's annoying to discover when building some extension that the Python headers are missing, but the rhetorical vehicle used in the Python community is to frame the distributions as people who like to move stuff around unnecessarily and to corrupt other people's work. In fact, the distributions have proven themselves to be quite competent at managing huge numbers of software packages in a semi-automated fashion, so it's baffling that people doing work on Pythonic packaging tools wouldn't want to learn as much as they can about how those people manage it. For me, when making Debian packages, it has become easier to use the debhelper stuff to install things like documentation and resources than it is to figure out which special options have to be passed to the particular distutils incarnation of the setup function in order to get such stuff put in the right place, especially since distutils probably still employs an ad-hoc 1990s proprietary UNIX "oh just dump that stuff in some directory or other and forget about it" mentality. Really, distutils should be all about *dist*ribution and even then get out of the way as much as possible - the hard stuff is extracting the appropriate knowledge about the built Python interpreter in order to build extensions. Installation should be left to something which has an opinion about where things should be placed on a particular system, and which has the capability to know how to uninstall stuff - a capability which never seems to get any closer in the distutils scene. Paul -- http://mail.python.org/mailman/listinfo/python-list
