timholy / Revise.jl

Automatically update function definitions in a running Julia session
https://timholy.github.io/Revise.jl/stable
Other
1.21k stars 110 forks source link

Should Julia recommend Revise? #564

Open timholy opened 4 years ago

timholy commented 4 years ago

Rationale

Most people who tune into Discourse know about Revise, but I'm guessing that's <1% of our user base. Those who think there isn't an efficient development workflow may be quickly discouraged from continuing to use Julia. A solution would be to have Julia itself recommend Revise when it detects that the user might be suffering from an inefficient workflow.

Risks

A hint could do more harm than good:

  1. users may know about Revise and deliberately avoid it (for such users, a periodic hint would be an annoyance)
  2. Revise might be confusing or make mistakes in some circumstances (we don't want to make development harder)
  3. there are other approaches to more efficient development (PackageCompiler, inline evaluation via the editor) and the tradeoffs are not easily summarized in a hint

Timing of this proposal

Relevant to "risk 2" above: until now, I didn't think Revise was ready to serve in this role---fine for people who chose it on their own, but not something I'd unflinchingly recommend to grandma. But from the relative lack of bug reports, Revise 3 seems pretty stable now, and in my own experience Revise3 is better than I am (whenever I think Revise has made a mistake, it almost always turns out that the mistake is mine). It also no longer requires sophisticated configuration; starting with Julia 1.5, it's potentially as simple as adding using Revise to your startup.jl. Finally, Revise3's latency costs--until you actually need that revision--are relatively low; you can feel them for very fast-to-load packages, but in more typical cases they seem to drop below the limit of perception.

Implementation

Up for grabs, but one thought would be to have a ~/.julia/logs/compile_history.toml file. This might look something like this:

hint_workflow = true
lasthint = 2020-10-24T05:41:39.867
used_Revise = 2020-10-24T06:05:18.085

[PkgA]
cachefile = [datetime1, datetime2, datetime3, ...]
cachefileb = [datetime1b, datetime2b, ...]

[PkgB]
...

Hints are disabled if hint_workflow is false. lasthint is used to determine the date & time of the most recently-issued hint; we might not hint more often than, say, once per month. used_Revise records the last time the user loaded Revise, and if within the last 6 months might also disable hinting. (This line would be absent if the user has never tried Revise.)

Suppose the settings of the previous variables are such that we've decided that this session could issue a hint, if user behavior justifies it. From there, the system would look for a recent history of frequent recompiles of a particular package with a particular cache file. If a threshold number is exceeded within, say, the previous hour, we issue the hint and then update lasthint to reflect that.

All of this would, of course, be implemented in Base.

clarkevans commented 3 years ago

The slower the box the more important Revise is. It's a critical part of my workflow. Moreover, since compilation time -- especially during interactive development -- is literally the 1st issue raised on public forums, it might really help adoption (especially those who oppose adoption) if Revise was packaged far more closely with the core project. Perhaps it should be built into the REPL. I want to run Revise on those packages I'm running "develop" on, or when including scripts. Hence, I'd go further than suggesting a hint -- I'd love to see how we could build it in tighter to the REPL. I think a generalized hint system is probably overthinking it. It should be something that is downloaded and enabled by default, in my opinion.

timholy commented 3 years ago

I wouldn't want it to be an unavoidable facility (when developing julia itself sometimes Revise helps but sometimes it gets in the way), but a "default install" seems like something worth considering.

lmiq commented 3 years ago

IMHO it shouldn't be suggested by Julia like that. I think what would be good is a rewrite of the Getting Started section of the manual including a description of good development workflows, with Revise being publicized there.

tknopp commented 3 years ago

Honestly, I think that a hint is not enough. What is needed is a command line switch in julia itself to switch between using revise or not. And the switch should default to using it. My proposal of course has some implications (i.e. integration of Revise as a stdlib).

timholy commented 3 years ago

Yeah, I've given serious thought about whether Revise should migrate to a stdlib. The problem, of course, is that bugs become all the more urgent. They still aren't at zero (just fixed one this morning). And I would understand reluctance on the part of the core devs to assume responsibility for maintaining Revise.

tknopp commented 3 years ago

We are on the same page here and I see the problems. Therefore this is something, which should be openly discussed with the core devs.

I personally do not care about installing Revise but the people I work with are not constantly screening discourse or the Julia docs. I regularly have the conversation: "Julia is so slow in loading packages", me: "aren't you using Revise?", answer: "what is Revise?".

The change is of course disruptive and needs consideration from the core devs. Still, my impression is that Julia core devs are not so reluctant on disruptive changes, in case that the benefits are obvious. When I look at the development model of Pkg.jl it also seems that we have found a way to keep stdlib in the package landscape but constantly pull in the newest version. This means that the development process for you as a package author is not made much more difficult as if code is moved to base.

Don't want to push anything but at least wanted to give my 2 cent on this subject.

PallHaraldsson commented 3 years ago

I would support Revise in Julia as a stdlib, but if you want to be cautions then an alternative plan to start with:

Include Revise in VS Code (and Pluto, etc.). It's the most popular IDE (50% of all, and I assume that's true for Julia too). I used it, and still sometimes REPL alone.

This could be a trial period, and since most users want an IDE, likely this one, you could reconsider later the REPL.

OhMyREPL.jl and maybe more should also be included...

timholy commented 3 years ago

Revise already partially interacts with those tools; I'm not entirely familiar with the limitations, to be honest. For example there was #527, and I use Revise & VSCode though TBH I tend to use Debugger.jl for debugging.

PallHaraldsson commented 3 years ago

I do actually see an old Draft: https://github.com/julia-vscode/julia-vscode/pull/1283

however @davidanthoff "force-pushed the ship-revise branch from 38dea51 to f5ee3ce 9 days ago" so is it already in? Only on master?

and already in changelog "Revise is now loaded without stealing the REPL backend for newer Julia versions." I think that mean if you had it installed, while seemingly own copy of Revise on master.

davidanthoff commented 3 years ago

Yeah, I still hope to ship Revise.jl out of the box with VS Code for the REPL and then just have a config option to enable or disable for it. Last time I checked this we had a problem that the debugger and Revise.jl in our custom-shipping configuration didn't work well together. Probably @timholy and I would just need an hour on a zoom session to figure out what is going on :) I have a bit more time these days than in the fall, so I'd be game.

What we already have is an option that will automatically load Revise.jl into the Julia REPL inside VS Code if a user has it installed. But that scenario doesn't help with installing it, it relies on the user getting Revise.jl themsevles.

PallHaraldsson commented 3 years ago

Seeing "I was about to give up on Julia until I found Revise. Without it, development in Julia is really painful."

and "Ship Revise" issue at vscode still being Draft, maybe Revise should simply be stdlib? Julia 1.7 is past feature freeze, but since I think most serious Julia users already use Revise, what's the danger including it? Would it be low-risk/easy change to add it?

I'm not too up-to-speed on stdlibs, could it be there, and your external Revise still be available? If it's simply a question of name conflict, then rename here to Revise-DEV? Revise in now version 3, seems might be stable enough for Julia, at least beating the alternative of no Revise, for the 99% of users?!