Reloading Modules

[oxinabox]

It would be nice if we could reload modules, rather than just Packages.
(alternatively it would be nice if it were documented)
Particularly since you can work on modules outside of a package.
But also because outside of Pkg functions, one never really thinks in terms of package names.
But in terms of modules. (even during package development)

Further, it would be nice, if reload(::Module) was defined.

I've not seen another issue, #12780 is related (but is abotu reloading files)

[stevengj]

See also #4008 and https://github.com/cstjean/ClobberingReload.jl

[stevengj]

I don't think reload requires something to be a registered package. It just needs to be a module in the load path.

[oxinabox]

I don't think reload requires something to be a registered package. It just needs to be a module in the load path.

That is what I thought. But after having some unusual behavour, I am just not sure.
So I looked at the documentation, and that says "package".
This might be mostly a documentation issue.

The weird behavior might be a bug, like mentioned in #4008, or some other bug.

If it is a documentation issue, though. The desire for reload(::Module) as a (fairly simple?) wrapper around reload(::String) still exists, as well.

[simonster]

reload has always worked as expected for non-package modules for me, but the documentation does look wrong.

[StefanKarpinski]

I would point out, as I did in a #265-related in-person discussion with @vtjnash, that what's actually wanted here is not really reloading module or packages: it's the ability to edit code and immediately debug the new version of the code in an already-running system. It does not need to happen via the same mechanism by which code was loaded in the first place. That's just one way that people try to accomplish this. This is often expressed by requesting very specific functionality wrt code loading, whereas what's really being requested is support for a use case.

[cstjean]

it's the ability to edit code and immediately debug the new version of the code in an already-running system

@stevengj mentioned it above, but FWIW, ClobberingReload.creload(module) does exactly that. And juno-atom has similar functionality.

[oxinabox]

Has anything changed WRT this now #265 is done?
In general reload should now be more sensible?

Doc's have not changed: https://docs.julialang.org/en/latest/stdlib/base.html#Base.reload
And does not look liked reload(m::Module) = reload(module_name(m)),
is defined.

So this is still pending?

[tbenst]

@oxinabox With using, code does not reload, but when qualified it does. I find that using introduces all sorts of namespace problems--most modern languages discourage namespace pollution, e.g. python's from x import *--so I prefer the latter example below even though it's verbose. I think the guide encourages using, but perhaps this will change as the package ecosystem further develops and namespace collisions become a more frequent problem.

module mymodule
export f
# try changing to 2*x after the first run
f(x) = 1*x
end

include("./mymodule.jl")
using mymodule
# no reload
print(f(2))

include("./mymodule.jl")
f = mymodule.f
# does reload
print(f(2))

[oxinabox]

Reload is gone in 0.7. so solved

[stevengj]

See also Revise.jl

[lewisl]

@StefanKarpinski You are right: this is a use case.

But a detail is perhaps missing. The module might not be in a package. It is simply in a local Julia source file. using, import, and reload work with packages. @cstjean mentions ClobberingReload.creload(module). I don't know where this is. And again, module is in the module name space of a Julia installation, which is established by loading packages.

The use case includes a need for a module that has not been turned into a package--it is just a bundle of functions. I thought I was cleaning up the source file by turning it into a module so that it could be cleanly used by other programs--like a package but just on my machine.

Perhaps I am just better off stripping away "module mymodule" in the file and including it as a source file. But, I did like the idea of only exporting the functions and types that were meant to be used from other code files.

Maybe this use case is really: make it much easier to get modules onto the search path of a local Julia installation without creating a package. The module documentation for 6.0 talks of module load paths and adding paths to LOAD_PATH. This is very unclear to me. A module doesn't exist in the file system: it is just a name given within a file. Unless there is a requirement that a module be contained in a file of the same name. But, this isn't documented and wouldn't make sense because a source file can contain multiple modules.

I am very confused by all this. The use case is a local thing that behaves like a module and is easy to reload while modifying and testing it. Someday it might be a package: another use case is simplifying the plumbing for packages.

Getting rid of reload in v 7 doesn't seem like it addresses either use case.

[StefanKarpinski]

Maybe this use case is really: make it much easier to get modules onto the search path of a local Julia installation without creating a package. The module documentation for 6.0 talks of module load paths and adding paths to LOAD_PATH. This is very unclear to me. A module doesn't exist in the file system: it is just a name given within a file. Unless there is a requirement that a module be contained in a file of the same name. But, this isn't documented and wouldn't make sense because a source file can contain multiple modules.

The code loading changes in 0.7 do clarify this: a package is anything that can be loaded by an absolute import, i.e. import X or using X, no more no less. It is no longer possible to define a module X in Main and load it from elsewhere via import X because Main is no longer where loaded packages are rooted (where they are rooted is not public). If you want to define a module and then import it, you have to use a relative import, i.e. something like this:

module M
    export x
    x = 1
end

using .M
# x is now available

The use case includes a need for a module that has not been turned into a package--it is just a bundle of functions. I thought I was cleaning up the source file by turning it into a module so that it could be cleanly used by other programs--like a package but just on my machine.

A package is on your machine. There's no requirement that a package be published or registered. It can even be a single source file: if dir is in your load path and dir/X.jl defines an X module then import X will load that file and make the module it defines available.

I'm unclear what any of this has to do with reloading... are you just using this issue as a place to ask for clarification about modules and packages or is there some connection to reloading code?

[lewisl]

Thank you. Both, perhaps. Reload comes up only as a way to make changes in a module, “reload” it, test it again. Now, I quit Julia, include(“ …”), using …, f(…) where f is an exported function in the module. I’ve gotten quick at that but it’s a pain. I was not aware I could import a file.

[cstjean]

@lewisl ClobberingReload is dead; use Revise.jl, and please ask questions on Discourse if you need further help.