Conflict with packages DifferentialEquation.jl, DynamicalSystems.jl, CairoMakie,jld

[Sergey_Novak]

Hello! I have updated the DynamicalSystems.jl package to the latest version, and the CaroMakie.jl and DifferentialEquations.jl packages have reverted to an earlier version. For what reason could this have occurred?
In addition, the CairoMakie has broken down a bit and now the scatter! does not work, giving an error.

`Makie.convert_arguments` for the plot type Scatter{Tuple{Int64, Int64, Int64}} and its conversion trait PointBased() was unsuccessful.

The signature that could not be converted was:
::Int64, ::Int64, ::Int64

Makie needs to convert all plot input arguments to types that can be consumed by the backends (typically Arrays with Float32 elements).
You can define a method for `Makie.convert_arguments` (a type recipe) for these types or their supertypes to make this set of arguments convertible (See http://makie.juliaplots.org/stable/recipes.html).

Alternatively, you can define `Makie.convert_single_argument` for single arguments which have types that are unknown to Makie but which can be converted to known types and fed back to the conversion pipeline.

UPD: The DynamicalSystems package update was done automatically when I added the BifurcationKit

[Sergey_Novak]

I was able to fix the errors in CairoMake, but I had to remove the BifurcationKit. I wonder why this package causes errors in CairoMakie

[rveltz]

To know that, try adding BifurcationKit and see the error message. I am surprised too

[Sergey_Novak]

For example my packages have last version without BifurcationKit

and CairoMakie is work.
And know i add BifurcationKit

UPD:
Error CairoMakie, BifurcationKit not using in code

`Makie.convert_arguments` for the plot type Scatter{Tuple{Float64, Float64, Float64}} and its conversion trait PointBased() was unsuccessful.

The signature that could not be converted was:
::Float64, ::Float64, ::Float64

Makie needs to convert all plot input arguments to types that can be consumed by the backends (typically Arrays with Float32 elements).
You can define a method for `Makie.convert_arguments` (a type recipe) for these types or their supertypes to make this set of arguments convertible (See http://makie.juliaplots.org/stable/recipes.html).

Alternatively, you can define `Makie.convert_single_argument` for single arguments which have types that are unknown to Makie but which can be converted to known types and fed back to the conversion pipeline.


Stacktrace:
  [1] error(s::String)
    @ Base .\error.jl:35
  [2] convert_arguments(::Type{Scatter{Tuple{Float64, Float64, Float64}}}, ::Float64, ::Vararg{Float64}; kw::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ Makie C:\Users\Alex\.julia\packages\Makie\NL7Xw\src\conversions.jl:17
  [3] convert_arguments(::Type{Scatter{Tuple{Float64, Float64, Float64}}}, ::Float64, ::Float64, ::Float64)
    @ Makie C:\Users\Alex\.julia\packages\Makie\NL7Xw\src\conversions.jl:7
  [4] plot!(::Scene, ::Type{Scatter}, ::Attributes, ::Float64, ::Vararg{Float64}; kw_attributes::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ Makie C:\Users\Alex\.julia\packages\Makie\NL7Xw\src\interfaces.jl:321
  [5] plot!(::Scene, ::Type{Scatter}, ::Attributes, ::Float64, ::Float64, ::Float64)
    @ Makie C:\Users\Alex\.julia\packages\Makie\NL7Xw\src\interfaces.jl:307
  [6] plot!(::Axis3, ::Type{Scatter}, ::Attributes, ::Float64, ::Vararg{Float64}; kw_attributes::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ Makie.MakieLayout C:\Users\Alex\.julia\packages\Makie\NL7Xw\src\makielayout\layoutables\axis3d.jl:276
  [7] plot!(::Axis3, ::Type{Scatter}, ::Attributes, ::Float64, ::Float64, ::Float64)
    @ Makie.MakieLayout C:\Users\Alex\.julia\packages\Makie\NL7Xw\src\makielayout\layoutables\axis3d.jl:266
  [8] plot!(::Type{Scatter}, ::Axis3, ::Float64, ::Vararg{Float64}; kw_attributes::Base.Pairs{Symbol, Any, Tuple{Symbol, Symbol}, NamedTuple{(:markersize, :color), Tuple{Int64, Symbol}}})
    @ Makie.MakieLayout C:\Users\Alex\.julia\packages\Makie\NL7Xw\src\makielayout\layoutables\axis3d.jl:284
  [9] plot!(::Type{Scatter}, ::Float64, ::Vararg{Float64}; kw_attributes::Base.Pairs{Symbol, Any, Tuple{Symbol, Symbol}, NamedTuple{(:markersize, :color), Tuple{Int64, Symbol}}})
    @ Makie C:\Users\Alex\.julia\packages\Makie\NL7Xw\src\figureplotting.jl:47
 [10] scatter!(::Float64, ::Vararg{Float64}; attributes::Base.Pairs{Symbol, Any, Tuple{Symbol, Symbol}, NamedTuple{(:markersize, :color), Tuple{Int64, Symbol}}})
    @ MakieCore C:\Users\Alex\.julia\packages\MakieCore\S8PkO\src\recipes.jl:35
 [11] top-level scope
    @ In[12]:14

[SteffenPL]

You can maybe run status --outdated in Pkg mode, to see what is blocking the update.
(See Julia 1.8 Highlights)

Also, trying to add CairoMakie@v0.10 might show you in more details what is blocking an update.

[Sergey_Novak]

Thank you!
It is output for CairoMakie

DifferentialEquations

[nilshg]

Don’t dump all your packages into the default environment, work with package specific environments instead. See eg

A guide: How to handle "ERROR: Unsatisfiable requirements detected ..."

Approximately once or twice a week (based on my feelings, not actual stats), I see a post asking about error: How to handle “ERROR: Unsatisfiable requirements detected …” It’s so common that I think it’s time for a systematic break-down of the issue. After reading this, you should be able to understand why this happens? and how to handle it. Deciding a package version Typically, a Julia package exists in multiple semver version. E.g. 0.1, 0.2, 0.3 etc. In general, when installing a package, …

or mt SO answer here on how to read the Pkg resolver output and workarounds:

Julia "Unsatisfiable requirements detected for package" error when installing multiple packages

[Sergey_Novak]

Thank you!
Multiple environments are inconvenient to use because of the long compilation of packages. Is it possible to compile all packages once?

[nilshg]

Compilation is once per environment. As you see putting all packages into one environment means you’ll likely run into compat issues, so I guess you need to decide what’s more convenient.

Also, having all packages in your default environment means that potentially lots of unrelated packages have to recompile when you add some package because some transitory dependency changed.

[Sergey_Novak]

I mean compilation when I call the package i.e using "CairoMakie"

[nilshg]

Packages are automatically precompiled when you install them into an environment. There is some additional compilation happening when you do using Package as well as when you first call some method from the package (“TTFX”, greatly reduced for many applications in the upcoming Julia 1.9).

All of this happens both in the default environment and in some separate project environment. The potential downside is that when you have one environment with say CairoMakie, DataFrames and one with CairoMakie, CSV you’ll precompile CairoMakie twice, while one environment with CairoMakie, DataFrames to which you then add CSV might only precompile once.

In any event the precompilation of a new environment should be on the order of 1 minute (unless you have a weak machine, especially single core) so it shouldn’t be a prohibitive cost.

[Sergey_Novak]

I have good machine and when i using

using StaticArrays, DifferentialEquations, DynamicalSystems, JLD, CairoMakie

Time running this code is ~2 min

[nilshg]

But again this has nothing to do with the environment you are using - using time is completely unaffected by this. I have been talking about precompilation which happens once per environment (change to an environment’s Project file). using cost is incurred once per session, which is a very different proposition.

If you are worried about this you should look into sysimages (maybe that’s what you meant by “compiling all packages once”?).

In any envent this is mostly unrelated the original topic of your thread which is version conflicts to which my answer remains: use a fresh environment with only the packages you need to minimize version conflicts.

[Sergey_Novak]

Yes, that’s what I meant
If I count something using one environment and then I want to plot a graph with a package that is in another environment then calculate something again in the previous environment, do I need to constantly switch between them?

[nilshg]

Generally people have one environment per project, which includes whatever packages they need for the specific analysis/task at hand (e.g. Counting, Plots in your case)

[Sergey_Novak]

In my case, using plotting and calculation together is not possible, because one package causes errors in the other. Apparently i will have to use two environments or use Plots instead of CairoMakie
Thank you

[nilshg]

Are you sure?

(@v1.9) pkg> activate --temp
  Activating new project at `AppData\Local\Temp\jl_P6XWmj`

(jl_P6XWmj) pkg> add StaticArrays, DifferentialEquations, DynamicalSystems, JLD, CairoMakie
    Updating `AppData\Local\Temp\jl_P6XWmj\Project.toml`
  [13f3f980] + CairoMakie v0.10.2
  [0c46a032] + DifferentialEquations v7.7.0
  [61744808] + DynamicalSystems v3.0.0
  [4138dd39] + JLD v0.13.3
  [90137ffa] + StaticArrays v1.5.17

seems to work just fine for me, with everything at the latest version.

[Sergey_Novak]

I meant CairoMakie and BifurcationKit. CairoMakie throws an error when I try to plot

[aramirezreyes]

~What was the call that failed with CairoMakie? Can you share the call and the types of the arguments?~

Edit: nevermind, it is pulling a super old call to CairoMakie

[nilshg]

Indeed BifurcationKit restricts CairoMakie to version 0.6, so you’ll either have to adapt your usage of CairoMakie to the API from that version (i.e. read the docs from back then) or indeed move to Plots (which seems useful in any case as BifurcationKit has recipes for Plots?)