Warn when a package loads a dependencies that already got loaded and that dependency has a different version than in the current manifest.

[KristofferC]

Imagine the following scenario: A user starts Julia in Juno (which loads a bunch of dependencies into Julia at startup). They then activate their project and loads a package. If that package shares any dependencies with Juno, the versions of the dependencies Juno used will be used for the package. These versions might be completely incompatible with the current project and can lead to silent errors in the code running.

Loading packages, changing project, and then loading more packages always have this risk but in the case where packages are loaded at startup, it might be hard to realize it is happening.

It might, therefore, make sense to warn in the case where a package tries to load a dependency and code loading sees that the dependency with that UUID is already loaded but at a different version than in the current project.

It could be argued that anyone that wants real reproducibility should run with a custom LOAD_PATH to only have the current project as the entry but I think that is quite rare in practice.

[davidanthoff]

Just as a FYI, this is actually the reason why we don't load any packages into the REPL process in the VS Code extension as a general policy.

[Seelengrab]

This has occured in the wild now, with a custom startup.jl that's loading & using JuliaFormatter before loading CSV (version 0.8.5, requiring Parsers@v1.1.2 at the maximum), which dies during precompilation due to not being compatible with the (by then) precompiled Parsers@v2.

For more information, see this thread on discourse.

[Seelengrab]

Another thread, this time with IJulia. The issue seems to happen in Atom as well, which makes sense if we think about how both of them work with code loading (being intrusive in the environments and all that).

[Seelengrab]

Since it happens with Conda.jl as well, I suspect this is a good bit worse - anything that happens to load Parsers@v2 (even rightfully so) where subsequently something else is bound to load Parsers@v1 will run into this and break, because there can only be one version of a package loaded at a time. In theory, downgrading the Parsers version by loading e.g. CSV.jl@v0.8.5 should cause Conda.jl to also reload, since either Conda.jl can’t rely on Parsers@v2 functionality that it’s now been compiled with, or CSV.jl breaks because it isn’t compatible with Parsers@v2. I have no idea why that's not the case though, was it not designed to do that?

The “general” solution should be to load packages in such an order that the versions of their dependencies grow maximally while obeying all versions bounds.