[Berthold Höllmann mentions...]
There is support for installing data files, but they get to data directories. When writing setup.py for biggles, I had the problem, that a config file had to go to the package directory. All I did was adding
class my_install_data (install_data): def finalize_options (self): self.set_undefined_options('install', ('install_lib', 'install_dir'), ('root', 'root'), ('force', 'force'), )
and
cmdclass = {'install_data': my_install_data}, data_files = [('biggles', ["src/config.ini"])]
to the setup command line. This got everything to the right place.
[Rene Liebscher replies...]
This is probably the simplest possible solution. My approach goes further, it handles also MANIFEST.in-like templates and some other special things, and it was written primary to replace distutils' install_data as whole. (Greg, do you remember my mail of 06/26/2000? http://www.python.org/pipermail/distutils-sig/2000-June/001671.html )
As it turns out, the Berthold's "my_install_data" solution is really a bare minimum -- the "install_data" command should work that way, or have an option to work that way. I wrote a setup script for IDLE that does basically the same as Berthold's, and if the Distutils installed their own config file, the Distutils setup script would also need this -- d'oh! I don't think I should have to extend the Distutils in order to install the Distutils -- droit de seigneur, in a sense. ;-) Rene, I originally thought your "DataFiles" concept was overkill, but I originally thought having a class to describe extensions was overkill too. If nothing else, introducing a simple class may be the only sane way to maintain backwards compatibility with the current "install_data class. Here's a somewhat simpler conception of the "DataFiles" class... DataFiles -- represents a collection of files to be installed in a common location, the "base directory". Files in the collection are fragmentary paths that are concatenated to the base directory at install time to create a complete installation path. The base directory may be a literal path, or it may use any of the configuration variables allowed in installation directories -- dist_name dist_version dist_fullname py_version py_version_short sys_prefix prefix sys_exec_prefix exec_prefix as well as the config vars corresponding to the installation directory options to the "install" command (most of which are just one of the entries in an installation scheme): install_base install_platbase install_root install_purelib install_platlib install_headers install_scripts install_data (?maybe obsolete?) Thus, a base directory of "$install_base" would expand to /usr/lib/python2.0/site-packages on a typical Linux installation, or C:\Python on a Windows installation. Or you could use "$install_base/mypkg" to install to (eg.) C:\Python\mypkg -- presumably the directory where modules from your distribution get installed. (As usual, Unix paths would be translated to native paths by the Distutils, so that setup scripts port across operating systems.) (There probably ought to be a special name for "the directory where the highest-level package from this module distribution is installed", which would expand to eg. /usr/lib/python1.5/site-packages/distutils.) This gets rid of dependence on the manifest machinery -- since that's now been factored out into a separate class (FileList, in distutils.filelist), developers can use it if they want. Or they can use the standard 'glob' module if that's good enough, or they can list files manually if *that's* good enough. Just off the top of my head... Greg -- Greg Ward - geek-on-the-loose gward@python.net http://starship.python.net/~gward/ I'll eat ANYTHING that's BRIGHT BLUE!!