Closed randyzwitch closed 6 years ago
Had the same issue. Pkg.checkout("Images") solved it for me. I am on v0.5.0 though.
Sorry I failed to notice this earlier, @randyzwitch.
CC @tkelman. I thought the resolver got improved in 0.5.1?
It did, but it can't do its job if you check things out to master. Probably due to GLPlot here. Can it be reproduced with packages all on release versions?
GLPlot doesn't pin versions:
tim@diva:~/.julia/v0.5/METADATA/GLPlot/versions$ grep -r Images *
0.0.1/requires:Images
0.0.2/requires:Images
0.0.3/requires:Images
0.0.4/requires:Images
0.0.5/requires:Images
tim@diva:~/.julia/v0.5/METADATA/GLPlot/versions$
Maybe one of the other packages at releases then, if they haven't had a new-Images-compatible release yet
Which packages still haven't released new-Images compatible versions?
I'll remind you of my concern about putting in upper bounds when we lack convenient tools to tell us where the conflict is coming from.
0.6 has better reporting on this, but that's not entirely backportable
see also https://github.com/JuliaLang/julia/issues/20313#issuecomment-289199920 - so if adjusting the resolver accuracy fixes this and it can't be reproduced with the 0.6 pkg code, then it's a case that was possibly fixed by the second resolver PR but not the first
If your concern about bounds is strong enough, then there's always the option of making major breaking changes to a widely used package via a new package name that can be installed at the same time, rather than in-place breaking changes which can't. It's doing things in-place that either puts a big divide through the space of available versions that forces the resolver to be entirely on one side or the other, or are very disruptive to downstream packages by breaking them by default.
All good points. In this case, I really want to keep the name Images.jl
though, since there's both a large installed base and a lot of references to that name out in the wild of the internet.
If we could drop the upper bounds on the grounds that packages have had the opportunity to release new-Images compatible versions, I would be happy. But I would understand if you don't want to do that, or if you think there hasn't yet been enough time. Which packages still have active upper bounds on their latest versions?
In any event, rest assured I'll keep you informed about such issues as they get reported :wink:.
Just ImageQuilting, w.r.t Images upper bounds. Should also check FixedPointNumbers.
Is this issue still valid @randyzwitch?
Not to me
Got this while running Pkg.update() on v0.5.2-pre+1, unfortunately not sure which package is causing the error: