only_once will be called multiple times

[stub42]

The guard used to stop only_once decorated code from running more than once includes the code line number in its key. The method will be run again if it is moved around the source file, or into a different source file for that matter. Which is fine, as I can argue that running only_once decorated methods once after every upgrade-charm hook is a good thing.

I think this should be explicit, rather than random, and the was_invoked/marked_invoked caches cleared at the beginning of an upgrade-charm hook. If people do need a only_once_really decorator, the developer would need to provide a key rather than a volatile one generated for them.

[galgalesh]

I'd argue against making this explicit. I think the main use-case for only-once is a handler that isn't idempotent, therefore it should never be allowed to run again, even during an upgrade-charm hook.

[stub42]

We have the choice between:

• leaving things as they are and documenting the current behaviour
• having only_once reset on upgrade-charm so they are always rerun on upgrade-charm rather than sometimes rerun on upgrade-charm
• requiring or optionally allowing the developer to add an explicit key
• deprecating only_once.

[galgalesh]

My vote goes to deprecation. The main use-case for only-once is a handler that isn't idempotent, such as formatting HDFS.

• Non-idempotent handlers are already an anti-pattern since a handler might run multiple times during debugging.
• The only_once functionality can be simulated by using states if you really need it.

Also, removing stuff just feels good :), removing complexity and such...

[galgalesh]

@stub42 , @johnsca ,

How do we go about deprecating this? Is there any way for us to give warnings at charm build time? Such functionality will also be useful for the 2.0 switch.

[ajkavanagh]

Over the years, I've written deprecate decorators of the form:

import functools


def deprecate(warning, logger=None):

    def wrap(f):
        _call_count = 0

        @functools.wraps(f)
        def wrapped_f(*args, **kwargs):
            nonlocal _call_count
            if not _call_count:
                # log or print deprecation here
                print(warning)
                _call_count = 1
            return f(*args, **kwargs)
        return wrapped_f
    return wrap


@deprecate("Don't use this")
def deprecated_function():
    # do something
    print("deprecated_function")


@deprecate("This one either")
def f2():
    print("f2 away")


deprecated_function()
deprecated_function()
f2()
deprecated_function()
f2()
f2()

with the corresponding output:

python3 test-deprecate.py
Don't use this
deprecated_function
deprecated_function
This one either
f2 away
deprecated_function
f2 away
f2 away

This has the advantage where the deprecated function will only log once, regardless of how many calls there are. It's then fairly easy to add a date to be removed and just grep the source to see when to remove it.

[marcoceppi]

Well, this will give a warning in the juju log, but not at build time. We could do a reactive event loop probe to register all the handlers and do deprecation notices at that time. That way we catch them at build.

…

On Wed, Feb 15, 2017, 07:07 Alex Kavanagh ***@***.***> wrote: Over the years, I've written deprecate decorators of the form: import functools def deprecate(warning, logger=None): def wrap(f): _call_count = 0 @functools.wraps(f) def wrapped_f(*args, **kwargs): nonlocal _call_count if not _call_count: # log or print deprecation here print(warning) _call_count = 1 return f(*args, **kwargs) return wrapped_f return wrap @deprecate("Don't use this")def deprecated_function(): # do something print("deprecated_function") @deprecate("This one either")def f2(): print("f2 away") deprecated_function() deprecated_function() f2() deprecated_function() f2() f2() with the corresponding output: python3 test-deprecate.py Don't use this deprecated_function deprecated_function This one either f2 away deprecated_function f2 away f2 away This has the advantage where the deprecated function will only log once, regardless of how many calls there are. It's then fairly easy to add a date to be removed and just grep the source to see when to remove it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAET1Q5H_0sAHVi0tAwX--ypAD7YEA4mks5rcup6gaJpZM4Gejub> .

[ajkavanagh]

If it was only wanted at build time (which, on reflection, might be more useful), then either a simple-ish regex of the source code would reveal if there were any only_once decorators.

An alternative solution might be to mock the only_once decorator and try to walk the built charm and import /reload all the modules which would spit out if it was being used. We do something similar in charms.openstack to verify which reactive decorators we have used during unit testing.

[galgalesh]

+1 for a regex. I have charms that require the hook env to be present during module load.

[marcoceppi]

regular experssion feels wonky to me, but if it can be done well and clean I'm not going to fuss either way.