I tried Pkg.update() and Pkg.add("DifferentialEquations") under the fresh condition, and finally managed to add the package! However, under this condition I couldn’t add Atom. I agree with @crbinz.
One was backported to 0.5.1, the other was not. One of the cases where the metadata sanity check failed yesterday would happen on 0.5.1 but not 0.5.0, which seems to have been a situation where the resolver got worse from one of the recent changes.
I’ll tag LSODA.jl soon. That’s the only package without a release to satisfy DiffEqBase 0.15.0. It’s not required by DifferentialEquations.jl, but I wonder if by its mere existence that’s what’s causing the downgrade. This “other package exists” being the problem would make sense with the METADATA sanity check issues we had.
LSODA.jl got tagged and I cannot recreate the problem anymore. Can someone else who was noting this give it a try?
If no one can re-create this anymore, then it’s definitely because the package resolver was being pulled back by LSODA, even if you didn’t have it installed.
Pkg.add(“Atom”) still downgrades quite a few packages, maybe forced by the downgrading of DiffEqBase?
julia> Pkg.add(“Atom”)
INFO: Installing ASTInterpreter v0.0.4
INFO: Installing AbstractTrees v0.0.4
INFO: Installing Atom v0.5.10
INFO: Installing Blink v0.5.1
INFO: Installing COFF v0.0.2
INFO: Installing CRC v1.2.0
INFO: Installing CodeTools v0.4.3
INFO: Installing DWARF v0.1.0
INFO: Downgrading DiffEqBase: v0.15.0 => v0.6.0
INFO: Downgrading DiffEqDevTools: v0.7.0 => v0.6.0
INFO: Downgrading DiffEqPDEBase: v0.2.0 => v0.1.0
INFO: Downgrading DiffEqParamEstim: v0.2.0 => v0.1.0
INFO: Downgrading DiffEqSensitivity: v0.1.0 => v0.0.4
INFO: Downgrading DifferentialEquations: v1.10.1 => v1.5.0
INFO: Installing ELF v0.1.0
INFO: Downgrading FiniteElementDiffEq: v0.3.0 => v0.2.1
INFO: Installing Gallium v0.0.4
INFO: Installing JuliaParser v0.7.4
INFO: Installing LNR v0.0.2
INFO: Installing MachO v0.0.4
INFO: Installing Mustache v0.1.4
INFO: Downgrading ODE: v0.4.0 => v0.3.0
INFO: Installing ObjFileBase v0.0.4
INFO: Downgrading OrdinaryDiffEq: v1.8.0 => v1.0.2
INFO: Downgrading ParameterizedFunctions: v1.3.0 => v1.2.0
INFO: Downgrading StochasticDiffEq: v1.4.0 => v0.5.0
INFO: Installing StructIO v0.0.2
INFO: Downgrading Sundials: v0.10.0 => v0.9.0
INFO: Installing TerminalUI v0.0.2
INFO: Installing VT100 v0.1.0
INFO: Removing DelayDiffEq v0.3.0
INFO: Removing DiffEqBiological v0.0.1
INFO: Removing DiffEqCallbacks v0.0.2
INFO: Removing DiffEqFinancial v0.1.0
INFO: Removing DiffEqJump v0.3.0
INFO: Removing DiffEqMonteCarlo v0.2.0
INFO: Removing MultiScaleArrays v0.1.0
INFO: Building HttpParser
INFO: Building Homebrew
Same for me. I still can’t install Atom and DifferentialEquations.
Something similar happens in Julia 0.6.
julia> Pkg.status()
8 required packages:
- Atom 0.5.10
- DifferentialEquations 1.10.1
- GLM 0.7.0
- Gurobi 0.3.1
- JuMP 0.16.2
- Plots 0.10.3
- PyPlot 2.3.1
- StatsModels 0.0.2
119 additional packages:
- ASTInterpreter 0.0.4
- AbstractTrees 0.0.4
- AlgebraicDiffEq 0.1.0
- ArgParse 0.4.0
- BinDeps 0.4.7
- Blink 0.5.1
- COFF 0.0.2
- CRC 1.2.0
- Calculus 0.2.2
- CategoricalArrays 0.1.3
- ChunkedArrays 0.1.1
- CodeTools 0.4.3
- Codecs 0.3.0
- ColorTypes 0.4.1
- Colors 0.7.3
- Combinatorics 0.4.0
- Compat 0.23.0
- Conda 0.5.3
- DWARF 0.1.0
- DataArrays 0.4.0
- DataFrames 0.9.1
- DataStreams 0.1.3
- DataStructures 0.5.3
- DataTables 0.0.3
- DelayDiffEq 0.3.0
- DiffBase 0.1.0
- DiffEqBase 0.15.0
- DiffEqBiological 0.0.1
- DiffEqCallbacks 0.0.2
- DiffEqDevTools 0.7.0
- DiffEqFinancial 0.1.0
- DiffEqJump 0.3.0
- DiffEqMonteCarlo 0.2.0
- DiffEqPDEBase 0.2.0
- DiffEqParamEstim 0.2.0
- DiffEqSensitivity 0.1.0
- Distances 0.4.1
- Distributions 0.12.5
- ELF 0.1.0
- EllipsisNotation 0.1.0
- FileIO 0.3.1
- FiniteElementDiffEq 0.3.0
- FixedPointNumbers 0.3.6
- FixedSizeArrays 0.2.5
- ForwardDiff 0.4.2
- GZip 0.3.0
- Gallium 0.0.4
- GenericSVD 0.0.2
- Hiccup 0.1.1
- HttpCommon 0.2.7
- HttpParser 0.2.0
- HttpServer 0.2.0
- InplaceOps 0.1.0
- IterativeSolvers 0.2.2
- Iterators 0.3.0
- JSON 0.9.0
- JuliaParser 0.7.4
- Juno 0.2.7
- LNR 0.0.2
- LaTeXStrings 0.2.1
- Lazy 0.11.6
- LearnBase 0.1.5
- LineSearches 0.1.5
- LossFunctions 0.1.0
- LsqFit 0.2.0
- MachO 0.0.4
- MacroTools 0.3.6
- MathProgBase 0.6.4
- MbedTLS 0.4.5
- Measures 0.1.0
- Media 0.2.7
- MultiScaleArrays 0.1.0
- Mustache 0.1.4
- Mux 0.2.3
- NLsolve 0.9.1
- NaNMath 0.2.4
- NullableArrays 0.1.0
- ObjFileBase 0.0.4
- Optim 0.7.8
- OrdinaryDiffEq 1.8.0
- PDMats 0.6.0
- ParameterizedFunctions 1.3.0
- Parameters 0.7.2
- PlotThemes 0.1.1
- PlotUtils 0.3.0
- PolynomialFactors 0.0.4
- Polynomials 0.1.5
- PositiveFactorizations 0.0.4
- Primes 0.1.3
- PyCall 1.12.0
- QuadGK 0.1.2
- Ranges 0.0.1
- Reactive 0.3.7
- RecipesBase 0.1.0
- RecursiveArrayTools 0.2.0
- Reexport 0.0.3
- ResettableStacks 0.1.0
- ReverseDiffSparse 0.7.2
- Rmath 0.1.6
- Roots 0.3.0
- SHA 0.3.2
- Showoff 0.1.1
- SimpleTraits 0.4.0
- SortingAlgorithms 0.1.1
- SpecialFunctions 0.1.1
- StatsBase 0.13.1
- StatsFuns 0.5.0
- StochasticDiffEq 1.4.0
- StokesDiffEq 0.1.0
- StructIO 0.0.2
- Sundials 0.10.0
- SymEngine 0.1.5
- TerminalUI 0.0.2
- TextWrap 0.2.0
- URIParser 0.1.8
- VT100 0.1.0
- VectorizedRoutines 0.0.2
- WeakRefStrings 0.2.0
- WebSockets 0.2.1
julia> Pkg.rm("GLM")
ERROR: resolve is unable to satisfy package requirements.
The problem was detected when trying to find a feasible version
for package ParameterizedFunctions.
However, this only means that package ParameterizedFunctions is involved in an
unsatisfiable or difficult dependency relation, and the root of
the problem may be elsewhere.
(you may try increasing the value of the JULIA_PKGRESOLVE_ACCURACY
environment variable)
Stacktrace:
[1] resolve(::Dict{String,Base.Pkg.Types.VersionSet}, ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}) at ./pkg/resolve.jl:48
[2] resolve(::Dict{String,Base.Pkg.Types.VersionSet}, ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, ::Dict{String,Tuple{VersionNumber,Bool}}, ::Dict{String,Base.Pkg.Types.Fixed}, ::Dict{String,VersionNumber}, ::Set{String}) at ./pkg/entry.jl:499
[3] resolve(::Dict{String,Base.Pkg.Types.VersionSet}, ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, ::Dict{String,Tuple{VersionNumber,Bool}}, ::Dict{String,Base.Pkg.Types.Fixed}) at ./pkg/entry.jl:479
[4] edit(::Function, ::String) at ./pkg/entry.jl:30
[5] rm(::String) at ./pkg/entry.jl:81
[6] (::Base.Pkg.Dir.##4#7{Array{Any,1},Base.Pkg.Entry.#rm,Tuple{String}})() at ./pkg/dir.jl:36
[7] cd(::Base.Pkg.Dir.##4#7{Array{Any,1},Base.Pkg.Entry.#rm,Tuple{String}}, ::String) at ./file.jl:70
[8] #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, ::Vararg{String,N} where N) at ./pkg/dir.jl:36
[9] rm(::String) at ./pkg/pkg.jl:97
julia> versioninfo()
Julia Version 0.6.0-pre.beta.187
Commit 55c97fb (2017-04-17 23:06 UTC)
Platform Info:
OS: Linux (x86_64-pc-linux-gnu)
CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.9.1 (ORCJIT, haswell)
Issues here as well. I managed to install by deleting most packages and putting DifferentialEquations (and a couple others) in REQUIRE. I was able to get Atom and DifferentialEquations that way. This is not only an issue with DifferentialEquations however. I had a similar problem just trying to update on an other computer (which was solved again by deleting everything).
I can’t add DifferentialEquations.jl now either. It’s crazy that we’re adding all these version bounds to prevent theoretical issues, while causing real issues for users.
3 Likes
As an update for users:
If you are having resolver issues, one way you can get around them in DifferentialEquations.jl is simply by directly using the component packages. For example, for solving ODEs you can directly use DiffEqBase plus an ODE solver. There is a package in the documentation which explains this further:
http://docs.juliadiffeq.org/latest/features/low_dep.html
Note that using DifferentialEquations.jl like this means that there won’t be default algorithms, so you have to tell solve which algorithm to use.
Have you tried increasing the resolver accuracy? It often works for me:
ENV["JULIA_PKGRESOLVE_ACCURACY"] = 10
Pkg.resolve()
FYI: while increasing JULIA_PKGRESOLVE_ACCURACY often lets the resolver run without apparent issue, I’ve found that it often installs out of date packages.
Oh, derp. Good to know, thanks!
Upper bounds have only ever been added because of real breaking changes. If there should be a feasible solution and nothing conflicts but the resolver says it does, it’s a resolver bug that needs fixing.
I have just tried adding DifferentialEquations and then Atom and didn’t have any issues.
If someone can provide me with a reproducible case where it fails, I’ll look into it.
2 Likes
Try adding Plots and ImageMagick. I had to do Atom → DifferentialEquations → Plots → ImageMagick to hit the bug on a clean install.
1 Like
On 0.6 those 4 seem okay. On 0.5.1 I see an issue, so I likely need to backport the second resolver-related PR from @carlobaldassi for 0.5.2.
Keep the test cases coming though, if you have any situations that work on 0.5.0 and don’t work on 0.5.1 or 0.6, or anything that doesn’t work on 0.6 period.
1 Like
Yes, those 4 packages install ok on 0.6, but in fact adding ImageMagick has 2 issues: 1) it doesn’t install the latest version (0.2.3 instead of 0.2.4) and 2) it triggers a downgrade of DifferentialEquations (1.10.1 to 1.5.0) and a few other packages.
Both issues can be fixed easily by setting a lower bound, i.e. Pkg.add("ImageMagick", v'0.2.4") and Pkg.add("DifferentialEquations", v"1.10.1"). The fact that both these work makes clear that there is an issue in the first place. I need to investigate the issue and try to figure out what’s going on and how to solve it best.
In the meantime, I suggest trying the lower-bound approach in general, whenever an issue is encountered, it should help the solver. Even more helpful would be pinning packages, since then those are completely removed from the resolution process (and have a cascading effect that simplifies the graph), but that is more drastic since then one loses the updates, therefore it’s probably best used only as a last resort.
3 Likes
Great! A repeatable bug and a temporary solution. That’s a good combination!
However, I plan on doing a big update soon (DiffEq 2.0). Should I hold off a bit so that way we can keep this test case in tact (just in case it accidentally fixes it?). I’d hope to release in a few weeks so it can settle before JuliaCon, but would like to keep this issue alive so a true fix can be found if someone is going to work on it in this timeframe.
It won’t be necessary, I’ll just keep METADATA in its current state locally when testing.
2 Likes