[Distutils] [Python Language Summit] Distutils / Packaging survey

[David Cournapeau]

Ben Finney wrote:
>
> I think you've not only simplified, you've done so in the wrong
> direction. I'd say instead that “datadir” is for *non-executable*
> files, and “libdir” for executable.
>   

It depends on what you mean by executable: it is obviously wrong when
executable = have the executable bit, so what do you mean by executable ?

The arch independent/dependent is much clearer IMHO, and is the
vocabulary used by the FHS, AFAIK. It is certainly the one used by the
configure script help:

  --bindir=DIR           user executables [EPREFIX/bin]
  --sbindir=DIR          system admin executables [EPREFIX/sbin]
  --libexecdir=DIR       program executables [EPREFIX/libexec]
  --sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR   modifiable architecture-independent data
[PREFIX/com]
  --localstatedir=DIR    modifiable single-machine data [PREFIX/var]
  --libdir=DIR           object code libraries [EPREFIX/lib]
  --includedir=DIR       C header files [PREFIX/include]
  --oldincludedir=DIR    C header files for non-gcc [/usr/include]
  --datarootdir=DIR      read-only arch.-independent data root
[PREFIX/share]
  --datadir=DIR          read-only architecture-independent data
[DATAROOTDIR]
  --infodir=DIR          info documentation [DATAROOTDIR/info]
  --localedir=DIR        locale-dependent data [DATAROOTDIR/locale]
  --mandir=DIR           man documentation [DATAROOTDIR/man]
  --docdir=DIR           documentation root [DATAROOTDIR/doc/libsndfile]
  --htmldir=DIR          html documentation [DOCDIR]
  --dvidir=DIR           dvi documentation [DOCDIR]
  --pdfdir=DIR           pdf documentation [DOCDIR]
  --psdir=DIR            ps documentation [DOCDIR]


After all, that's one of the rationale for the FHS: some files are
shared by different computers, some are not.

> That something is non-executable usually means that it's
> “architecture-independent”, and traditionally, “executable” has
> meant “architecture-dependent”,

I don't understand this in the context of python: most python
executables are architecture independent (python scripts). For example,
/usr/bin/ipython is a python script.

>  but I don't think that's a necessary
> distinction here. Viz. the placement of the Python standard library,
> including mostly architecture-independent executable files, in a
> “libdir”.
>   

I think we should stop thinking, and start looking :) Here are some
files as packaged in the python-numpy Ubuntu package package:

/usr/bin/f2py -> (default) python script
/usr/bin/f2py2.4 -> 2.4 script
/usr/bin/f2py2.4-dbg -> 2.4 debug script
...
/usr/lib/python2.4/site-packages/numpy/core/_dotblas.so -> C extension,
obviously arch dependent.
...
/usr/share/doc/python-numpy/CAPI.txt.gz -> some doc
/usr/share/pyshared/numpy/__config__.py -> the python scripts


So you have things which are supposed to be called from the shell in
bindir, the C extension in libdir, the python code in datadir, the docs
in docdir, etc...

>
> That would lead to a misguided attempt to keep ‘foo.py’ separate from
> the resulting ‘foo.pyc’, which would be far more pain than it's worth
> AFAICT.
>   

There is no .pyc in a debian package: they are computed at installation
time. The .pyc and .so are put in
/usr/lib/python2.5/site-package/package-name, but the .py are not (they
are softlink to the actual .py, which are in
/usr/data/pyshared/package-name).

David