Comment 8 for bug 636193

On Thu, Jan 6, 2011 at 1:36 PM, Robert Collins
<email address hidden> wrote:
> On Fri, Jan 7, 2011 at 4:18 AM, Benji York <email address hidden> wrote:
>> On Wed, Jan 5, 2011 at 6:01 PM, Robert Collins
>> <email address hidden> wrote:
>>> So a registry is one approach.
>>>
>>> Another is to scan the code for flag names that are used. I'm kindof
>>> partial to this simply because of the strong schemaless design.
>>
>> I considered that approach.  A purely textual scan doesn't seem like it
>> will work because we get a lot of testing related false hits.  Analysing
>> the AST seems like it would suffer from the same problem.
>>
>> Do you have another approach or variant that would perform better?
>
> Well, the only false hits we should expect are those testing feature
> flags themselves - and they are blacklistable.

Seems hacky to me -- which is saying something ;) -- but it may be our
only choice given my understanding of the below.

> A registry would be ok - I don't want to dictate implementation - but
> lets not make it hard to work with. Uhm, what does that mean?

1)
> We shouldn't have to make changes in lp.services.features when we use a
> new feature flag;

Easy enough.

2)
> we shouldn't have to make changes in lp.services.features when we add a new
> component to lp.

Makes sense.

3)
> we shouldn't need to fiddle with zcml in those cases either.

Darn. You got me there. I had planned on using the ZCA as the
registry, adding an entry when defining a new feature flag, like so:

  <utility
      provides="lp.services.features.interfaces.IFeatureFlag"
      name="hard_timeout" />

I had planned on doing something similar for scopes.

Other registry-based options I can see are having an "add_feature_flag"
function, but that would mean calling it at import time which is
generally a bad idea or a purely data-driven registry (list of tuples or
similar) in a centralized place which would seem to violate 1 (unless we
put it in a place other than lp.services.features, which seems odd).

I'm out of registry-based ideas that either aren't good ideas or don't
violate your three conditions.

> Not too that the bug I filed asks for the scopes and flags to be
> listed in API doc, *not* for runtime warnings or other such things.

I don't think I appreciate the full meaning of the above. Are you
saying a manually maintained (and therefore potentially incorrect)
textual description of the available flags and scopes work?
--
Benji York