Problems with stacked environments

General Usage
1

I often see this: Why?

WARNING: redefinition of constant OpenSSL_jll.PATH. This may fail, cause incorrect answers, or produce other errors.
WARNING: redefinition of constant OpenSSL_jll.LIBPATH. This may fail, cause incorrect answers, or produce other errors.
WARNING: redefinition of constant OpenSSL_jll.PATH_list. This may fail, cause incorrect answers, or produce other errors.
WARNING: redefinition of constant OpenSSL_jll.LIBPATH_list. This may fail, cause incorrect answers, or produce other errors.
┌ Error: Error watching manifest
│   exception =
│    MethodError: no method matching (::OpenSSL_jll.var"#make_wrapper_dict#6"{OpenSSL_jll.var"#parse_wrapper_platform#5"})(::String, ::Vector{String})
│    The function `make_wrapper_dict` exists, but no method is defined for this combination of argument types.
│    Stacktrace:
│     [1] top-level scope
│       @ C:\JuliaPackages\packages\JLLWrappers\GfYNv\src\toplevel_generators.jl:167
│    Revise evaluation error at C:\JuliaPackages\packages\JLLWrappers\GfYNv\src\toplevel_generators.jl:167
│ 
│    Stacktrace:
│     [1] methods_by_execution!(recurse::Any, methodinfo::Revise.CodeTrackingMethodInfo, docexprs::Dict{Module, Vector{Expr}}, mod::Module, ex::Expr; mode::Symbol, disablebp::Bool, always_rethrow::Bool, kwargs::@Kwargs{})       
│       @ Revise C:\JuliaPackages\packages\Revise\mLfYT\src\lowered.jl:306
└ @ Revise C:\JuliaPackages\packages\Revise\mLfYT\src\pkgs.jl:498
2

Julia version?

3

1.11.4

4

If I have to blindly guess I’d say you have a stacked environment with different versions of openssl_jll in different layers of the stack.

1 Like
5

I load my base env in the startup.jl

try
    @eval begin
        using Revise
    end
catch e
end

and then my “project” environment, which I have to activate. How is the recommended way of handling Revise.jl loading? Should I rather have it in my project env?

6

I don’t think it’s a problem of Revise per se. Having different package versions in stacked environments is bound to bear problems eventually one way or another, the only thing to do is not to have different versions (can’t say I like the package manager allowing this).

But this is again my blind guess without knowing what you’re doing, you’ll have to inspect your environment and tell us if my hypothesis was correct.

7

So, loading anything in the startup.jl is bad?

8

If I have a project folder, e.g.

.
├── README.md
├── julia
│   ├── A_folder
│   │   ├── A_script.jl
│   │   ├── Project.toml
│   ├── B_folder
│   │   ├──B_script.jl
│   │   ├── Project.toml

When I have a Project.toml for A and for B, can I safely switch between them? Or should I simply have one root Project.toml? When I open VSCode in the root I cannot activate the sub-environments anyway via the extension.

9

Not necessarily. It’s stacking environments with different versions of packages which is potentially problematic.

Where are the Manifest.toml files? They have the versions of the package, that’s where you should look into. But also, you likely have the global environment in .julia/environments/v1.X, that could be the base of your stack.

Again, it depends on whether all versions of packages are the same. Even if there are some which are different you may not observe issues in practice though.

10

Sry, I omitted them. The Manifest.toml are at the same location as the Project.toml.

It might very well be. That is the only reason I divide the environments.

I guess, with this approach, it is far easier to have different versions loaded.

11

Just one last thing, what would be the “Julian” way of handling this? I.e. having Revise.jl loaded globally, and switching between environments?

12

Searching through the VSCode settings, it appears that I do not have to do that at all:

image