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

Re-export deprecated bindings #28

Closed
mzgubic opened this issue May 27, 2021 · 5 comments · Fixed by #29
Closed

Re-export deprecated bindings #28

mzgubic opened this issue May 27, 2021 · 5 comments · Fixed by #29

Comments

@mzgubic
Copy link

mzgubic commented May 27, 2021

This came up recently when we renamed a few types in ChainRules, which uses @reexport macro to reexport the ChainRulesCore differential types, e.g. Zero was renamed to ZeroTangent.

This broke ReversePropagation tests (as part of the ChainRules integration tests suite) because ReversePropagation only depends on ChainRules directly (rather than ChainRulesCore), and did not understand the deprecated Zero.

@ararslan
Copy link
Collaborator

So is the proposal here to have @reexport using X avoid exporting a binding if it's deprecated by X? Note that would turn deprecations, which are typically non-breaking, into hard errors downstream.

@oxinabox
Copy link

I think the opposite, I think the problem is right now it doesn't reexport the old names?

@johnnychen94
Copy link

johnnychen94 commented May 27, 2021

The problem is that my_old_sum now is not exported so it breaks other people's code.

julia> module LargePackage
           using Reexport

           module SmallPackage
               export my_new_sum

               my_new_sum(A::Tuple) = reduce(+, A)

               Base.@deprecate_binding my_old_sum my_new_sum
           end

           @reexport using .SmallPackage
       end # module
Main.LargePackage

julia> using .LargePackage

julia> my_old_sum((1, 2))
ERROR: UndefVarError: my_old_sum not defined
Stacktrace:
 [1] top-level scope
   @ REPL[3]:1

Curiously, if we use @deprecate here it just works.

@ararslan
Copy link
Collaborator

Curiously, if we use @deprecate here it just works.

That's because the expansion of @deprecate includes an export by default. One of the arguments to the macro toggles that.

@ararslan
Copy link
Collaborator

Okay, I see the problem now: names doesn't see deprecated bindings by default (that's documented). I think that instead of iterating over names(M) for M a Module, we'd need to do something like

for binding in names(M; all=true, imported=true)
    if Base.isexported(M, binding)
        # reexport binding
    end
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants