[Distutils] First attempt: close but no data files!

[P.J. Eby]

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
>>>for a
>>>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
>in it.

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.  ;-)