Deprecating reload("Compat") to Base._require(Base.PkgId("Compat")); Base.root_module(Base.PkgId("Compat")) has made this operation much harder to type. Revise.jl is great, but it doesn't seem essential to remove this function entirely. I don't think we're planning on making this impossible?
reopens #18659
It reload is only ever called in top-level code, it's fine for it to be single-argument like this. If anyone uses it from within a dependency to reload one of its dependencies, however, it's going to possibly load the entirely wrong thing. If that's thoroughly documented, we can reintroduce the function. However, I think this is a good time to ponder if we really want this – what are we really trying to accomplish when we reload something – and if we can accomplish that in a better way.
I think the API for this should probably be calling reload(ABC) where ABC is the package module object and it should be an error to pass a module that's not a root module (aka a package). That API cannot be misused so easily. Similarly, I think that APIs where someone wants the path to some package code should take the module object since that will work regardless of the context.
Open question: if LOAD_PATH and DEPOT_PATH have changed since ABC was originally loaded, should reload(ABC) reload the code at the original location or load the version that a fresh import ABC would load based on what's currently in the path variables?
I don't care at all, since it'll never matter. Just make it work.
Open question: if
LOAD_PATHandDEPOT_PATHhave changed sinceABCwas originally loaded, shouldreload(ABC)reload the code at the original location or load the version that a freshimport ABCwould load based on what's currently in the path variables?
It seems to me that reload should always emulate what a fresh import ABC would do.
The Revise workflow has important limitations. It cannot handle type changes or changes in dependencies of loaded modules.
Most helpful comment
I think the API for this should probably be calling
reload(ABC)whereABCis the package module object and it should be an error to pass a module that's not a root module (aka a package). That API cannot be misused so easily. Similarly, I think that APIs where someone wants the path to some package code should take the module object since that will work regardless of the context.