Making Revise the default?

[Palli]

I would NOT like Revise be used as default, or added to Base, for one reason. But see opposite argument of mine below.

I’m trying to make Julia’s sysimage (and Base preferably) smaller, I’m already made startup 30% faster, so I would fear this addition, and it making it slower.

This applies for running a script, but much less for a REPL. I see what Revise is for:

Revise can assist with methodologies like test-driven development.

I think you assume people use the REPL for development (true, but not all).

Could we have our cake and eat it too, by only include Revise in the REPL (and by extension e.g. VS Code, I think it may already; and Pluto)?

@ChrisRackauckas

I would propose the following steps:

1. Move Revise.jl to Base and enable it by default.
2. Move Revise.jl documentation to be a section in the Base documentation. Can better integrate it in the near future.
3. Change include’s behavior to be that of includet, and make a new includent

On 1. I don’t like adding it to Base, it is (all of it?) precompiled into the sysimage. I suppose at least include is… Could it stay as is, for running scripts, but if the REPL is used then an implied using Revise is done, plus it would redefine include to includet? Or in some way using that conditionally.

About 2. it should be mentioned in Julia’s docs (is already?) at least somewhere, maybe not under Base.

I must admit I’m not a user of Revise (unlike 80%+), I know of it, and probably added it at some point (for any benefit?) without explicitly ever using includet that I still sort of knew of. Maybe that means I’m not a serious Julia user…

Since you used that term “user”, then I think you had “developers” in mind, and I’m more of the latter, though they overlap for many users. I do note however that it seems not just for the REPL, but also I see at juliahub that Revise has 98 dependents. I’m not clear on why packages use it in production, and that might invalidate my scripting arguement, or not since putting it as a dependency in Project.toml should still work.

@ChrisRackauckas

Sometimes people don’t learn how easy Revise is because it’s not a part of the “standard Julia installation”. Yes it’s only a single character difference and these issues are solved, but removing that single character difference and making its docs part of the standard Julia documentation would make things a million times easier. Agreed.

Do you know the potential speed-difference, if e.g. you just include a file ones? I’m not sure what the t does, I mean track, but at runtime, in case of no modifications, nor if you include the same file again?

[ufechner7]

I don’t think includet should be the default because it is somewhat dangerous: It hides bugs in the sense that it results in misleading error messages. I often need to replace includet with include before I see the real error message of a problem.

[tecosaur]

Would it be worth considering making Revise a stdlib instead of moving it into Base?

[ShalokShalom]

Is there a tracking issue of this?

[tim.holy]

The way to strip down Revise’s dependencies is to log more data at the time of the method-definition. That has to be in Julia’s core. Of course, logging more data blows up the size of your running session, and there’s a lot of interest in making Julia leaner. I’m sure there’s a reasonable solution (likely involving environment variables), but it’s a big project and I don’t foresee having a couple months to work on it anytime soon.

[tecosaur]

I see, thanks for responding. It sounds like both a base and stdlib approach would be possible then, just requiring extensive changes in base either way?

[tim.holy]

Well, to make Revise.track(Base) work, ideally you’d like all that functionality available before defining any method. The issue is that one thing Revise does is set up a mapping method signature => Expr (see How Revise works · Revise.jl) so that it can map backwards from stacktraces and correct line numbers in files that are being edited. (If you’re making changes but stacktrace line numbers are all wrong, it quickly gets frustrating.) So some of this functionality needs to be available so early that Base’s own code can be logged.

So most likely, some of the core functionality is going to have to be added to Julia’s internal C code. Putting it in a stdlib is far too late.

Revise currently works by retrospectively setting up these mappings, but nearly all Revise bugs come from corner cases where re-parsing and re-lowering introduces problems. It’s also why the whole Revise stack is huge: we need JuliaInterpreter to almost execute the source files that define Julia code, intervening at the last possible moment to extract the signature without rewriting the method definition. This is an insane amount of effort to have to go to, and I will be glad to drop it, but we may have to wait until JuliaSyntax subsumes lowering as well as parsing so that all the provenance issues can be resolved.

[lewis]

If you assume it can be “built-in” then there may be other efficiencies, even with the option to turn it off.

I think the grumbling might relate to some exaggeration of difficulty, the lack of discoverability, and not opting for a very desirable default behavior. And the long time it has taken, even though everyone (among the maintainers) seems to agree, suggests some resistance to change that has valid reasons others far away from the implementation of Julia aren’t aware of.

Since “everyone” seems directionally onboard, an announcement of intention for a future release, possibly accompanied by an explanation of the benefits of actual integration (vs. loading by default and changing the aliases of 2 functions) is very much worth the extra time to get it in, may settle the discussions down.

[mst]

@ChrisRackauckas

Change include’s behavior to be that of includet, and make a new includent that is the untracked version. Change the docstring and docs in Base for include to mention the difference between the two and improve the discoverability of includent, though heavily suppose that the tracking behavior is what the vast majority wants.

Why not just change includet to track? This would avoid redefining include in your brain. Alternatively, should include change to includet’s behavior, well I suppose then you would need untrack — I’d say this would be much cleaner way to differentiate than that pesky terminal t. My two cents.

[ChrisRackauckas]

That sounds fine.

[ShalokShalom]

Yeah, very welcome. I personally detest abbreviations a lot, since they only add confusion, and leave it up to the imagination what is meant anyway.
So having a policy to forbid them in the first place, is something I would suggest as well.

Changing include to includet’s behavior, breaks the workflow of many people, who might be used to that command, and even use it in scripts.

That’s another thing, I would never do