2009/7/7 Nick Coghlan <ncoghlan at gmail.com>:
> For *nix, the obvious use case is installing scripts somewhere like
> /usr/bin or /usr/local/bin.
Using distutils' scripts option, they will end up in : sys.exec_path/bin
Another use case I've found in a distro I've installed this afternoon :
setup(..., data_files=[('/usr/share/man/man1/', ['SOMEFILE'])], ...)
That's not the most elegant way to add a man page, but for someone
who doesn't bather with APT or whatever, it works to build a binary
distribution.
>
> One option is to punt on this whole issue and say if people want to
> install stuff outside the Python module heirarchy they should create
> their own OS-specific package to manage it (i.e. leave the non-relative
> paths to be managed by APT or a Windows installer or whatever).
If so, what do we do with the "data_files" option in distutils ?
If it's used with absolute paths, files can be installed anywhere on
the system, and we want to track them.
Even if we don't uninstall them automatically, they should be tracked
so a third-party
uninstaller can deal with them properly.
Or do we change this distutils feature and state that the directories
used in "data_files"
will always be relative to sys.prefix ?
That would bring us back to three cases in the RECORD:
- files located under sys.prefix, but not located under site-packages
- files located under sys.exec_prefix, but not located under site-packages
- files located under site-packages
Where "site-packages" is the directory that contains .egg-info
directory of the distribution
(that's basically the current PEP state, beside the absolute paths
case we would need to remove)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4