On Thu, Sep 20, 2012 at 10:19 PM, Stanley A. Klein <skl...@cpcug.org> wrote: > So, please add the FHS issue to your list. > > I've also found that everything seems to be in a state of flux right now, > with setuptools, distribute, distutils, distutils2, and > pypi2rpm/bdist_rpm2 all out there and bumping into each other. When I > tried to do a yum update to my Fedora 14 system, I ran into trouble > because of conflicts among these packages. I hope this all settles down > soon.
The FHS issues are on the list, which is why there are "resource categories" that can be installed wherever in new-packaging land. Unfortunately my experience is that system Python packaging doesn't work for application developers. That is why developers remove themselves from the system Python as quickly as possible by using virtualenv or by compiling an up-to-date version of Python, and use only the packages installed in that virtualenv. It's unfortunate because there are a few impossible-to-compile things like qt or cairo bindings that would be really nice to be able to get at, but for example if I install the wrong packages on Ubuntu, "python -c 'import keyring'" segfaults. The GTK/gobject bindings are also fraught with peril. Basically Python's site-packages directory is the equivalent of automatically re-linking every C program with every library in /lib every time a new library is installed. We could use a solution that is like egg except politically acceptable. Maybe an import hook that knows which top-level packages you actually want, and hides the complexity of excluding the other ones instead of producing a gut-wrechingly long sys.path... _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
