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