[Distutils] First attempt: close but no data files!
pje at telecommunity.com
Fri Oct 23 18:08:59 CEST 2009
At 08:53 AM 10/23/2009 -0700, Kaelin Colclasure wrote:
>On Oct 23, 2009, at 8:16 AM, P.J. Eby wrote:
>>At 09:58 PM 10/22/2009 -0700, Kaelin Colclasure wrote:
>>>Restructuring as a package did indeed get things working as expected.
>>>It's somewhat unfortunate that this is a requirement, as it made
>>>lot of noise in my Mercurial repository and now most of my code is in
>>>a module with the unhelpful name __init__.py
>>Given how short your data file is, the fact that it's entirely text,
>>and the fact that your module script always needs it to be loaded, I
>>wonder why you don't just make it a string constant in the .py file
>>to start with, or better yet, simply directly create the data
>>structure it represents.
>I think you're referring to cuttlefish-config.plist, which is intended
>to be edited after installation to refer to the particulars of the
>installed site's filesystem, etc.
Don't do that. Package data is for static, read-only data used by a
library or application at runtime.
> [And yes, I realize having such a
>config file live inside the package is sub-optimal. I'm just looking
>for a low-impedence solution that works with the PyPI infrastructure.
>That said, if there are "best practices" for such things established
>and supported by setuptools I'm all ears
Put it with documentation, or use the standard distutils data_files
option, rather than package data. User editable files should *not*
be installed adjacent to the code; it's rightly frowned on by Linux
distributions and system administrators everywhere.
If the issue is that it's a "global" configuration file and you don't
know where else to put it, base the location on the user's home
directory (on *nix ) or an APP_DATA subdirectory (on Windows).
If it's not a single per-user location, then use an environment
variable or command-line option (for command-line tools) or as an
argument (for Python APIs).
Some tools also ship with a lot of package data as *templates* for
user-configurable stuff, and include a short script to copy the
template to a user-specified location, possibly filling in a few
things specified on the command line, or via interactive
prompts. This is a good way to provide a nice UI for your
installation/setup, especially in the case where someone might need
multiple copies of the configured data (e.g. a webapp you can install
multiple instances of, like Trac).
>There is also a 'static/' directory with a bunch of webapp resources
If those are user-editable, it's probably a good idea to include a
script that copies and/or customizes them and places them in a
user-defined location, rather than having the code read them directly
from the package (and thus requiring the user to edit them
directly). Of course, if those webapp resources are *not*
user-editable, then leaving them in your package data is fine.
> And it is now installing with the package perfectly too. Thanks
>again for the helpful guidance!
You can thank me (and make a lot of sysadmins happier, or at least a
little less grumpy) by not locating any user-editable files inside
your package directory. ;-)
More information about the Distutils-SIG