2009/7/7 Nick Coghlan <ncogh...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com