I’m currently using Revise.jl in VS Code julia extension to track changes and update my code along the way.
In particular, I am working on a package that has OrderedCollections.jl as an indirect dependency.
So far I just had Revise.jl in my global environment and it was automatically loaded by VS Code-julia transparently.
Recent changes in either Revise.jl of VS Code-julia, I am not sure when or where this happened, lead to bugs or repeated precompilation of the packages in the dev-ed environment, and the finger is pointed at OrderedCollections as Revise.jl depends on it. Reloading julia only repeats the same problem.
My immediate solution was to add Revise.jl to the dev-ed environment to ensure homogeneous versions of the dependencies and deactivated the automatic loading.
I’m just wondering if it is a wrong usage on my part of the tooling or if it is some issue that I fail to properly understand.
global env is empty. This is what I teach my students
you go to VSCode. By default (unless you opt out) revise is added to the global env and loaded by default on the session
revise accepts both OrderedCollection 1 and 2, but because it is loaded “alone” by default, OrderedColelction v2 is loaded
if you open VSCode on an environment where you have packages that depend on OrderedCollection 1 only (like DataFramesMeta and others UNTIL 2 DAYS AGO), then Julia complains that the wrong version is loaded and it needs to recompile everything all the time, causing biiiig delays in packages precompilations.
The specific problem with the packages I use has been solved 2 days ago by updating the upper bound of compact in the affected packages, but it can come again, or it may still affect other less frequently updated packages.
I’m not sure it is a good idea to offer as default the option to have revise be loaded on automatically everywhere… if they are not experienced julia users, most likely they don’t need revise. Most people work with data, they don’t even know what a type/struct is. Then, if they are more advanced, they know what they are doing and either they set revise up automatically on or they manually add it when needed.
So, my proposal is either to have the option to add ‘revise’ to auto-load on VSCode off by default, or modify (if possible) revise such that it doesn’t depend on other packages.
This happens because then Revise is in the same Project of your dev code and resolve to use OrderedCollection v1 instead of being loaded first, and load OrderedCollection v2, but it’s not nice to have Revise in the Project of a package, as this is a development tool, not somethign used to run the package.
Try to update your manifest or your project’s Package.toml.. there is a chance that the packages that are dependencies of your package now accept OrderedCollection v2 (some did in the last few days)
Thanks for the feedback. This is very close to my own observations. I also updated the dependency that kept OrderedCollections.jl from updating.
I assumed that having Revise.jl in the package environment was not the proper way to go. I’m glad you confirm this.
It seems that currently the option loads Revise.jl before activating the current environement, wouldn’t loading Revise.jl after activating the environment solve the issue ? That would potentially lead to recompiling Revise.jl for this environment wouldn’t it ?
yes, if you disable the automatic load of Revise in VSCode, then julia will resolve your project only once with a version of the packages that suit all the dependencies (if this is possible)
Ideally (and that may be one alternative), Revise should have its own bundle the all dependencies (private copies of them), such that they do not conflict with any environment. This is what the VSCode extension does, as far as I understand.
I have been experiencing this issue lately, and it is indeed annoying.
Yes, what I meant is that maybe just swapping the order between loading Revise.jl and activating the environment in the julia-vscode extension should be enough to avoid such issues.
But that would still lead to re-compilations per environment, which is not ideal @lmiq’s idea is probably better.