* 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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
