On Thu, Feb 5, 2009 at 3:37 PM, Andreas Zeidler <a...@zitc.de> wrote:
> On Feb 5, 2009, at 9:29 PM, Andreas Zeidler wrote:
>> i noticed that. in fact, i was trying to figure out how the assigned value
>> ("plone") ended up in `module_name`. i
>> ended up looked at the entry point's (the one you get from
>> `pkg_resources.iter_entry_points`) `__dict__`, assuming
>> that some magic in `pkg_resources` would translate the "target" to be meant
>> as the module's name. but apparently
>> all given value end up as `module_name` in the dict. i suppose i should
>> have had a closer look at entry point definitions first.
Ah, yeah, a single entry point basically models a dictionary entry:
`module_name` is (part of) the entry point's "value", which is
imported as a Python object; `name` is the "key". So an entry point
"fleem = my.app.module:func" looks like
{{{
>> ep
EntryPoint.parse('fleem = my.app.module:func')
>> ep.name
'fleem'
>> ep.module_name
''my.app.module'
>> ep.load() # basically `from my.app.module import func`
<function func at ...>
}}}
The entry point object also has a reference to the egg (distribution)
that provides it. That's just about all they are, it's simpler than
the pkg_resources docs make them sound. :)
>> yes, [using an arbitrary entry point name instead of `target`] works. in
>> any case this should be documented, though.
Yeah, I'll work on this over the weekend. The docs in general need
some cleaning up.
>>> Perhaps z3c.autoinclude could check if
>>> `os.environ.has_key('Z3C_AUTOINCLUDE_DISABLED')` and the test runner and/or
>>> a buildout option could set that environment variable?
>>
>> yep, also +1. after all, that's exactly what environment variable are for,
>> aren't they? :)
OK, z3c.autoinclude trunk as of r96193 checks for
'Z3C_AUTOINCLUDE_PLUGINS_DISABLED' and
'Z3C_AUTOINCLUDE_DEPENDENCIES_DISABLED' in the environment.
> i forgot to mention that it'd be great if you could try to work these out
> until some time next week. technically the revision deadline is this
> saturday, of course, but since my review was several days late, i think it's
> only fair to still grant you a full week to address these issues. i hope the
> delay doesn't cause too many inconveniences and you'll find the time it
> takes...
n/p, none of this has been too time-consuming yet :)
Thanks,
Ethan
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
