At 08:57 AM 8/22/2006 +0100, James Casbon wrote:
>I have an app which makes heavy use of rich ini style configuration files.
>I would like to add the ability to extend it using pkg_resources entry
>points. It seems quite natural here to use the entry point to refer to
>the plugin configuration data like so:
>something = pkgfile:extension/config.ini
>This single point would allow me to get the config data for the
>plugin. Now, at the moment this style of entry point is not supported. I
>could potentially get round this by asking all plugins to define an entry
>point method that returns the location of the configuration file, but that
>just creates another piece of tedious boilerplate to write.
>So, I'm wondering whether the inability to supply pkgfiles as entry points
>is a deliberate design decision or just something that hadn't been anticipated?
It wasn't anticipated, and yes, there have been other things that have come
up since where it would've been useful (e.g. i18n).
I considered making some changes to the format to allow some extensibility,
but there isn't an easy way to maintain compatibility across setuptools
versions with such changes.
So, instead my thought is this: setuptools already allows any characters
you want on the left side of the '=' sign, except for '='. So, you already
have the ability to add arbitrary metadata to an entry point's name, e.g.:
something (file:config.ini) = packagename
As long as you do the parsing in your own code, this will work with any
setuptools version. The string can be arbitrarily long, too, so you could
define any number of 'prefix:value' variables.
In general, I'm thinking that setuptools 0.7 will offer some kind of
built-in (but optional) support for this kind of parsing and metadata, so
that you can both specify it more easily in setup.py and handle it more
easily in code.