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
vtjnash
All 5 comments
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.
StefanKarpinski
on 24 Jan 2018
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.
StefanKarpinski
on 25 Jun 2018
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?
StefanKarpinski
on 25 Jun 2018
I don't care at all, since it'll never matter. Just make it work.
vtjnash
on 24 Jul 2018
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.
cossio
on 16 Oct 2018
Related issues
Keno
·
3Comments
sbromberger
·
3Comments
musm
·
3Comments
wilburtownsend
·
3Comments
TotalVerb
·
3Comments
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.