[Distutils] extra files into the package dir

Greg Ward gward@python.net
Tue Nov 7 21:58:01 2000

[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 --

  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_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 Ward - geek-on-the-loose                           gward@python.net
I'll eat ANYTHING that's BRIGHT BLUE!!