[Distutils] distutils: packaging a generated configuration file

2009-10-05 Thread Mark Dickinson
I'm trying to use distutils for the first time to package up a
project, and struggling a bit;  I wonder whether some kind soul could
point me in the right direction.

I'm packaging a pure Python project that uses ctypes.  The only
complication is that I'd like the setup script to install a
configuration file alongside the various .py files.  From the
documentation, this sounds like something that would usually be
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.

I could just generate the 'config' file in the top-level package
directory, but it seems dangerous to assume that that directory is
writable; it seems better to use one of the build directories that
distutils already knows about.

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.

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

Any hints?

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


Re: [Distutils] distutils: packaging a generated configuration file

2009-10-05 Thread Wolodja Wentland
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


signature.asc
Description: Digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig