[Python-Dev] PEP 376 - Open questions

[Ben Finney]

Paul Moore <p.f.moore at gmail.com> writes:

> The only cases I know where there is reason for a package to store
> paths outside the package directory are:

I think the *only* files that actually belong in the package directory
are the Python modules inside that package. Other files need to be
easily, and automatically, separable for purposes of installation.

> - executable scripts, which go in sys.prefix/Scripts on Windows

    os.path.join(sys.prefix, 'Scripts')

> and ??? on Unix/MAC OS

Depending on whether the developer designates the programs for
sysadmin-only use or not:

    os.path.join(sys.prefix, 'bin')
    os.path.join(sys.prefix, 'sbin')

> - supporting files (MoinMoin puts its HTML documents etc in
> sys.prefix/share on Windows, cx_Oracle puts its documentation in
> sys.prefix/cx_Oracle-doc)

This category, it seems to me, needs to be expanded with metadata that
allows “purpose”-based tagging, so that platform-specific standards
can be applied using those purposes to determine the correct location
for these non-Python-module files.

> Support files are getting put in the package directory more often
> these days

Only, IMO, because there's no way of flagging it as anything but
arbitrary “data”.

Examples of purpose-based classifications that need to be distinctly
declarable: executable program, importable module source,
platform-independent compiled module, platform-dependent compiled
module, documentation, run-time variable data, static data,
configuration, and so on.

All of these (and others I've forgotten) should be possible for the
developer to declare in distribution metadata, and the installer can
then use those declarations to make the files go to platform-specific
locations, not the Python package directories.

> For Windows, having a few distinguished locations under the
> installation root (scripts, share, doc) would probably do. For Unix
> and Mac OS, I have no opinion (but I suspect that absolute paths like
> /usr/local/bin might be the norm there).

The lines are drawn in different places on each platform; we don't want
to have the union of all these different platform-specific locations in
the standard, and likewise we don't want to leave any of them with
second-class support.

I think it's not the developer's burden to decide *where* such files go;
rather, they should be declaring only the *purpose* of these files in
the distribution metadata, and it's up to the site-specific installer
(possibly as configured by the installing user) to decide the location
of each file by its declared purpose.

-- 
 \      “I can picture in my mind a world without war, a world without |
  `\   hate. And I can picture us attacking that world, because they'd |
_o__)                                   never expect it.” —Jack Handey |
Ben Finney