[Framework-Team] PLIP #247 ready for review (I think)

Ethan Jucovy ethan.jucovy at gmail.com
Fri Feb 6 23:56:58 UTC 2009


On Thu, Feb 5, 2009 at 3:37 PM, Andreas Zeidler <az at 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




More information about the Framework-Team mailing list