Open timholy opened 4 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.
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.
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.
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).
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.
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.
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...
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.
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.
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.
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?!
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:
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: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.