When ITensors in dev mode, modifications to existing functions are recognized but new functions are not

Question

I have a question regarding ITensors.jl in development mode. I have ITensors in the .julia/dev folder, since I am trying to made modifications to the ITensors.jl code itself for my applications.

I have noticed that, if I modify an existing method in a file in ITensors (for instance, adding a print statement to one of the dmrg functions in src/mps/dmrg.jl), I can see that change reflected immediately in any code I run that calls that function. However, if I create a new method in one of the existing files, then this change fails. Just as an example, I did this with a very simple addition to src/mps/dmrg.jl:

function test_function()
  println("You made it!")
  return 0
end

I then made another file with just two lines of code:

using ITensors
my_var = test_function()

And here is the output I got when running this file:

ERROR: LoadError: UndefVarError: test_function not defined
Stacktrace:
 [1] top-level scope at d:\Sujay Google Drive\Julia 
Files\J1_J2_model_custom_periodic_dmrg.jl:32
 [2] include(::String) at .\client.jl:439
 [3] startdebug(::Base.PipeEndpoint, ::VSCodeDebugger.var"#3#4"{Tuple{String,String}}) 
at c:\Users\user\.vscode\extensions\julialang.language-julia- 
0.17.7\scripts\packages\DebugAdapter\src\packagedef.jl:89
 [4] startdebugger() at c:\Users\user\.vscode\extensions\julialang.language-julia- 
0.17.7\scripts\packages\VSCodeDebugger\src\VSCodeDebugger.jl:38
 [5] top-level scope at c:\Users\user\.vscode\extensions\julialang.language-julia- 
0.17.7\scripts\debugger\run_debugger.jl:7
 [6] include(::Module, ::String) at .\Base.jl:377
 [7] exec_options(::Base.JLOptions) at .\client.jl:288
 [8] _start() at .\client.jl:484
in expression starting at d:\Sujay Google Drive\Julia 
Files\J1_J2_model_custom_periodic_dmrg.jl:32

Why is this? Is there something different about creating a new function, as opposed to modifying an existing one, that leads to the former change not being incorporated into some other piece of code that uses that function? I can post

Answer 1

Hi Sujay,
I believe the reason you are seeing this is because you are creating new functions inside of the ITensors module (which is fine) but then not listing these function names as "exported". So they are only remaining accessible as ITensors.function_name rather than just function_name. Or you can explicitly import them by doing import ITensors: function_name in your driver code.

We keep all of the ITensors exports in the file src/exports.jl

Best,
Miles

Comments

Thank you so much Miles! That indeed resolved my issue. I guess I never needed to open that file until now, since until now my edits were always within an existing method, rather than creating a new method. Looking at that file cleared up most things, although the lingering question I have is this: why are there some methods that you don't export? For instance, I notice that you don't export makeL! and makeR! from projmpo.jl, and you don't export anything from projmps.jl.

---

We try to be as conservative as possible about what we export.

Exported functions form what is as close to possible as the "official" interface, i.e. until we release version 0.2.0 of ITensors.jl, we try our best to not change the behavior of exported functions (except for adding on new functionality). Functions that are not exported indicate to the user that they are more "internal" functions, i.e. their behavior might change between minor versions (like from version 0.1.20 to 0.1.21). There may be different reasons for not exporting a particular function. For example, we may not be totally happy with the names (for example, `makeL!` and `makeR!` are not the best, and don't follow our all-lower-case naming style). Some functions like that may only be used by a very small number of more advanced users, so it is safer for us to not export them and indicate to people to think twice about using them and expect them to possibly change in the future.

Basically, if we exported every function, it would be very hard for us to develop the library without breaking user code, or have a stable interface! But if there are functions that you use a lot that you think should be exported, please let us know and we can work on exporting them. Sometimes it is difficult to anticipate what functions are generally useful vs. mainly of interest for internal use.