Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

logging future warnings #50

Closed
edublancas opened this issue Mar 15, 2023 · 6 comments · Fixed by #65
Closed

logging future warnings #50

edublancas opened this issue Mar 15, 2023 · 6 comments · Fixed by #65
Assignees
Labels
good first issue Good for newcomers stash Label used to categorize issues that will be worked on next

Comments

@edublancas
Copy link
Contributor

whenever we have to change the API, we display a FutureWarning to users so they have a chance to update their code. However, we don't know the proportion of them that already switched.

It'd be better to log these events, so we know when users need more time to switch because we want to ship new features as fast as possible without compromising stability.

We can add a telemetry.deprecation_warning method that uses warnings.warn (with FutureWarning) and captures the event.

@edublancas
Copy link
Contributor Author

FYI @idomic

@tonykploomber
Copy link
Contributor

Do you mean every time we show the future warnings, meanwhile we will log the event to PostHog?

@edublancas
Copy link
Contributor Author

a function that will show a FutureWarning, but also log the event to posthog

@idomic
Copy link
Contributor

idomic commented Apr 20, 2023

@tonykploomber please write an AC of what you think is expected here before starting on this.

@tonykploomber
Copy link
Contributor

Acceptance Criteria:

We want to record:

  • The consumer function name of each function in src/ploomber_core/depreciated.py
    (e.g. add has @deprecated.function decorator, we need to know add was called and send to posthug
@deprecated.function(deprecated_in="0.1", remove_in="0.2")
def add(x, y):
    """
    Notes
    -----
    .. deprecated:: 0.1
        ``add`` is deprecated, will be removed in version 0.2
    """
    return x + y
  • versionadded argument value
  • deprecated argument value

@edublancas Let me know if this makes sense to you.
For the implementation, I guess we want to have a new method like log_deprecation_warning which similar to log_call in telemetry?

And we want to make it as the decorator function and apply it to parameter_renamed, parameter_deprecated, function, method... to collect the complete data of those calling metadata

@edublancas
Copy link
Contributor Author

edublancas commented Apr 26, 2023

We created the @deprecated.* decorators when we were mostly working in sklearn-evaluation. Ironically, now that we shifted to JupySQL, these decorators are not very relevant since the user interacts with JupySQL via the %sql magic, instead of importing and calling regular Python functions. So what I'm proposing is something simpler like this:

from warnings import warn

def deprecation_warning(message):
    warn(message, FutureWarning)
    # also log the event to posthog

Then, if in JupySQL we want to deprecate %sql --some-argument, we can do:

if args.some_argument is not None:
    deprecation_warning("--some argument has been deprecated")

Later, we can decide if we also add posthog calls to the @deprecated decorators, but for now, we don't have to.

@edublancas edublancas added good first issue Good for newcomers stash Label used to categorize issues that will be worked on next labels May 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers stash Label used to categorize issues that will be worked on next
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants