Does Reexport break Revise?

General Usage
1

Suppose one is defining the following package:

module MyPackage
    using Reexport
    @reexport module Sub
        export f
        f() = 0
    end
end

Let’s now play with it using Revise:

using Revise
using MyPackage
MyPackage.Sub.f()  # returns: 0 
MyPackage.f()      # returns: 0

Now, suppose I modify the source code of my package to define f() = 1 instead. Then, I get the following:

MyPackage.Sub.f()  # returns: 1
MyPackage.f()      # returns: 0 (!!)

Note that the first (correct) call also prints the following warning:

WARNING: replacing module Sub.
WARNING: using Sub.f in module MyPackage conflicts with an existing identifier.

Is there something I am missing here? Reexport.jl is a pretty standard and widely used package and so I have a hard time imagining that it is breaking the Revise workflow.

Note: I am using Revise v3.3.3, Reexport v1.2.2 and Julia 1.7.3.

1 Like
2

Update: the problem does not happen with the following package:

module MyPackage
    using Reexport
    module Sub
        export f
        f() = 0
    end
    @reexport using .Sub
end

This is surprising to me since I thought these package definitions were basically equivalent. Os it it that Revise does get confused when a submodule definition is prefixed by a macro call?