support /usr/local/share/* installation

[majuscule]

Currently, setuptools supports package installation to /usr/local/bin via entry_points in setup(). For all other files it appears that MANIFEST is recommended, which bundles non-code files into the package distribution directly. This is not useful for resources whose destination pathing is expected by system utilties - such as manual pages under /usr/local/share. This presents a large painpoint. Example: beetbox/beets#1501 (comment)

I see value in keeping package files as as discreet as possible, however the current API of entry_points leads to incomplete command line interfaces.

I think it would make sense to introduce support at least two additional parameters:

setup(
    ...
    manuals=['path/to/man.1', 'path/to/man.2'],
    share=['path/to/share/dir']
)

These resources would still be distributed via MANIFEST or package_data, but would now be accompanied by symlinks to the appropriate directories. This is similar to how Homebrew distributes resources out of the Cellar.

[jaraco]

This issue shares concerns with #130 and may be a duplicate. Can you read up on that issue and see if it applies here and if the solution would work for your use case?

One concern about the addition of manuals and share metadata is they may be poorly-defined on Windows systems. Python and its packaging system strives to provide a unified, first-class experience on all platforms, so adopting support for Unix-specific constructs would need to at least address those concerns.

[majuscule]

I believe that these issues are closely related but not duplicates. It may be easiest to consider #130 a superset of this issue; whereas the solution there would support my usecase, I am suggesting a more contained alternative.

Please correct me if I have misunderstood the discussion there.

#130 makes the argument that install_data should support arbitrary destinations via the --prefix flag, and a (the most?) common usecase presented is manual pages and other system-wide data in /usr/local/share. However this presents security and usability concerns, namely overwriting important file hierarchies and uninstallation proceedures.

Here I am proposing a more controlled alternative, borrowing from the long-standing egg exception for /usr/local/bin you noted and maintaining only "wrapper/symlink" presence outside of the install directory. Additionally, first-class support for these common usecases will simplify package development for a large number of packages that otherwise are forced into acrobatics or omission for manual support. Furthermore, I would push to support uninstall similarly to entry_points.

Concerning Windows systems I lack the experience to suggest an equivalent. Perhaps %ProgramData%\<package> ?

[mpounsett]

I'd like to echo support for the notion of an entry_points-like feature to support installation into /usr/local/share. This seems to be highly sought after functionality that would support installation of example code, documentation, license files, etc., which appears to be a fairly common support question in places like Stack Overflow.