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. ;-)
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
