On Mon, Oct 05, 2009 at 20:02 +0100, Mark Dickinson wrote:
[...]
> specified with 'package_data' or 'data_files'.  The catch is that
> parts of the configuration file are generated at setup time:  that is,
> the setup script gathers various pieces of system information (e.g.,
> library locations) and uses those to transform a hard-coded
> 'config.in' file into the 'config' file that I want to install.
[...]

How do you get this data? (just curious)

> What's the best way to manage generation and installation of the
> config file?  I've got as far as subclassing the build command and
> making __run__ create the config file from the config.in file, putting
> it into the build_temp directory;  I can't figure out how to tell
> distutils to install it in the right place.

What do you consider right place? Where do you expect your config file
to be installed and how do you find it from within your code?

> It seems like I want a sort of build_data/install_data pair of
> commands, that allows creation and installation of *generated* data
> files.

I have been in a similar situation some time ago and had one simple, but
unsupported, need when packaging data files. I wanted to access them
from within my code after they have been installed. I detailed the
problems in [1].

The solution I came up with [2] was to subclass the build_py command in
distutils, include a 'build_info.py' at the package root and modify that
file within the subclassed build_py command. I am still not sure if that
is a good approach and haven't got any feedback on it.

If the config file you want to install is *not* a python module and you
expect it to be installed in DATA_PREFIX/config you might have some
success with subclassing the install_data command, modify the config
file before it is copied and include the file with package_data or
data_files. You could also try to modify the data_files attribute of
that problem if you can't specify all generated data files beforehand.
But that might just cause havoc and major breakage...

Note that installing data files within the python package violates the
FHS, so I would recommend using data_files, if you are interested to
have your software included in any *nix or BSD distribution. You will
still have a problem to find it later on though.

I hope that helps and I am *very* interested in any other way to solve
this. 

good luck

    Wolodja Wentland

[1] http://mail.python.org/pipermail/distutils-sig/2009-September/013238.html
[2] http://mail.python.org/pipermail/distutils-sig/2009-September/013284.html

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to