[BUG] using RecipesBase: @recipe is broken

[LilithHafner]

The output of @recipe assumes that RecipesBase is loaded. This makes using RecipesBase: @recipe not work. Ideally, it should work, failing that, documenting the limitation would be nice.

[t-bltg]

This makes using RecipesBase: @recipe not work

Do you have a reproducer at hand ? What is exactly failing ? Please describe as if I were a 5 y.o.

[LilithHafner]

Do you have a reproducer at hand ?

I copied this from https://github.com/JuliaPlots/Plots.jl/tree/master/RecipesBase

julia> module M
           using RecipesBase: @recipe
           struct T end
           @recipe f(::T) = rand(100,100)
       end
Main.M

julia> using Plots

julia> surface(M.T())
ERROR: UndefVarError: RecipesBase not defined
Stacktrace:
 [1] apply_recipe(plotattributes::AbstractDict{Symbol, Any}, #unused#::Main.M.T)
   @ Main.M ~/.julia/packages/RecipesBase/6AijY/src/RecipesBase.jl:298
 [2] _process_userrecipes!(plt::Any, plotattributes::Any, args::Any)
   @ RecipesPipeline ~/.julia/packages/RecipesPipeline/XxUHt/src/user_recipe.jl:38
 [3] recipe_pipeline!(plt::Any, plotattributes::Any, args::Any)
   @ RecipesPipeline ~/.julia/packages/RecipesPipeline/XxUHt/src/RecipesPipeline.jl:72
 [4] _plot!(plt::Plots.Plot, plotattributes::Any, args::Any)
   @ Plots ~/.julia/packages/Plots/YbrTT/src/plot.jl:223
 [5] plot(args::Any; kw::Base.Pairs{Symbol, V, Tuple{Vararg{Symbol, N}}, NamedTuple{names, T}} where {V, N, names, T<:Tuple{Vararg{Any, N}}})
   @ Plots ~/.julia/packages/Plots/YbrTT/src/plot.jl:102
 [6] surface(args::Any; kw::Base.Pairs{Symbol, V, Tuple{Vararg{Symbol, N}}, NamedTuple{names, T}} where {V, N, names, T<:Tuple{Vararg{Any, N}}})
   @ Plots ~/.julia/packages/RecipesBase/6AijY/src/RecipesBase.jl:428
 [7] surface(args::Any)
   @ Plots ~/.julia/packages/RecipesBase/6AijY/src/RecipesBase.jl:428
 [8] top-level scope
   @ REPL[5]:1

What is exactly failing ?

The unqualified symbol RecipesBase appears in the macroexpansion of @recipe ... but when that result is evaluated, the symbol is not found in the namespace of the enclosing module (M).

[t-bltg]

Thanks, I see we'd have to think of a fix (as maybe initiated in #4559) or enhancing documentation indeed.