Is there a way of getting Revise working on files included with Requires? My experience is files included in a @require block don’t get updated with Revise.
1 Like
If you can put together a simple demo that I can copy/paste and reproduce the issue, there’s a chance this is fixable.
3 Likes
Seeing this involves file loading I made a test package. Load with this script:
]dev https://github.com/rafaqz/ReviseTest.jl
using Revise
using ReviseTest
using Images # trigger the @require block
julia> testfunc()
1
# Then change the output of testfunc() in YOURDEVFOLDER/ReviseTest/src/testfile.jl
julia> testfunc()
1
# It should still return 1...
3 Likes
There’s a potential solution here. Comments, testing, and/or help figuring out why it doesn’t work on Windows would be appreciated.
Thanks! That works perfectly on linux. Sorry I can’t test on windows.
The only issue is @require blocks are getting awfully long, and not really DRY. It would be great if Requires could notify Revise automatically of new files, but I understand the performance issue is probably more important.
This now works if you use Requires 1.x and Revise 2.4.
It is likely that many packages need to bump their [compat] for Requires 1.x.
2 Likes
@tim.holy thank you for the update. This is an issue that always affected my development workflow. I wonder if this Requires.jl + Revise.jl combination could be made part of the language? That is, users wouldn’t need to use the packages explicitly in their projects, and the macro @require would be exported by default from some stdlib.
Requires.jl, Requires.jl, OhMyREPL.jl, TestSetExtensions.jl and other packages are so useful in day-to-day Julia programming, they improve user experience by a lot in my opinion.
I am assuming you are suggesting that these packages are bundled as standard libraries? Just note that Revise.jl alone had 5 releases in the past 30 days, while Julia (with the standard libraries) is released roughly 2-3 times a year.
Just pkg> adding these is not that much of a hassle; from then on the user experience is the same.
1 Like
No, I’m suggesting that users can just develop their packages with a simple @require macro in their init function. The automatic recompilation of Revise.jl would be built-in and no need for adding the packages as dependencies in Project.toml etc.
Imagine that you’re are newcomer, there is a lot to grasp just to develop a package with optional dependencies and automatic recompilation.
There is a Pkg issue for conditional dependencies with a proposal and discussions: https://github.com/JuliaLang/Pkg.jl/issues/1285, which looks like a better way to do it than requires and more likely to make it in to a standard library (Pkg).
1 Like
I am sorry, but I don’t understand what you are proposing. Are you talking about __init__()? How is it related to Revise.jl?
The functionality provided by Revise.jl is not tied to packages, or even modules, and is orthogonal to optimal dependencies. It’s just that in practice it was not working until recent updates.
Hopefully optional dependencies will just be managed by the loader at some point so package developers will not have to use these hacks, and Revise.jl will just continue to provide a great, but essentially independent convenience feature.
I thought my comment was clear, but I will try to rephrase it for you to follow.
Imagine you are a newcomer and you have no idea about Revise.jl Requires.jl. now you simply want to start coding your package with optional dependencies, interactively changing the code, and running scripts to test. What do you do? Well, this should just work the newcomer thinks. What is the current reality though? Oh I need to add Requires.jl to my Project.toml, I need to import it in the module. I then need to edit my init function to add a call with @require, oops but that needs a hash code that I need to lookup somewhere. Ok found it. Now let’s try to rerun the test script. Oops it didn’t update. I need to import Revise.jl in my test script… is it clear the issue? Do you agree this experience isn’t the smoothest?
I agree that optional dependencies could be handled on the Pkg side. That would make life easier.
The runtime loading of code that Requires does has some issues (no precompilation and not easy to do “static compilation”). I think an “official” conditional dependency strategy need to solve those problems.
2 Likes
There are many things to unpack here.
First, while I agree that everything should be as smooth as possible, I don’t think that the notion of code activated by optional dependencies is such a standard or widespread feature as you imply — not all languages have something similar built-in. It is certainly useful, but I don’t think that it’s something newbies should or will start with. Indeed the whole thing could be smoother, but it is just one of the many minor annoyances that are in the process of being improved.
Second, that “hash code” (the package UUID) will remain an essential part of the process, and has to be specified like in other contexts — see one of the recent proposals. Tooling of course can make it easier to manage when unambiguous (like pkg> add does now).
Third (and sorry to keep repeating this) Revise.jl is a convenience feature conceptually unrelated to conditional code loading. Of course the implementation isn’t, but now that it works smoothly it is not something that affects users.
Finally, Requires.jl is essentially very clever hack, and everyone agrees that a mechanism like this should be supported by the loader directly. It is very likely to be part of the language in the medium run, once the details are hammered out.