* installing by just copying python files to /usr/share/themole is far from elegant.Uh? This is the idiomatic way to install Python applications.are you sure?
Well, I've been reviewing packages implemented in Python for over 2 years. You are the first person who questioned my expertise on this subject. So while I feel now a bit embarrassed, yes, I'm sure.
i've made a short survey by looking at files in /{{usr,}/{s,}bin,usr/games}/ and looking for symlinks to /usr/share to as python scripts (found five distinct packages doing that: gdebi, gtg, python-xlrd, and upnp-inspector), looking for things that modify PYTHONPATH (only paraview and non-python stuff), and looking for scripts that do sys.path.append to use usr/share (no matches, but i've just written two bug reports after going through occurrences of path.append, one of them security critical)so all in all, of those 76 packages that install python scripts to the PATH (not counting the ^python packages), only half a dozen try to load code directly from /usr/share. the others either have very small executables (which reside solely in the bin folder and don't have any auxiliary code) or use pyshared or dist-packages.
It's a bit hard to me to comment on your numbers, as I don't know which packages did you look at.
So instead I did my own survey. I analysed all (164) binary packages (co-)maintained by Python Applications Packaging Team in unstable/main.
- 20 don't ship any Python module at all. - 73 ship private modules. - 77 ship public modules. (By simple math: - 6 ship both private and public modules.) Amongst those that ship only public modules: - There are 7 python-$something packages.- There are at least 15 packages (mercurial-*, trac-*, maybe more) that are plugins to other software. Directory layout of such packages is determined by layout of software they extend.
It is true that there's non-negligible amount of Python scripts that are thin wrappers over some public Python modules. Sometimes it's because upstream provides (more or less) well-defined and (hopefully) stable API to be used by other software. (Please note that it's certainly not the case for themole!) In such case, the modules should be in sys.path and the package name should be python-$something.
Sadly, often the only reasons behind installing stuff into public places are:
1) poor support for such arrangement in distutils;2) Debian maintainer(s) being either too lazy to fix it, or being ignorant of namespace pollution.
-- Jakub Wilk