Part of the issue here is dependency resolution is a global feasibility problem, each package imposes a subset of constraints. So you can identify active / free constraints at a solution, but it can be hard to assign blame to a single package in general.
On Saturday, July 23, 2016 at 7:37:50 AM UTC-7, Chris Rackauckas wrote: > > Another +1. When Optim.jl tagged v0.5, it took me too long find out it was > responsible for rolling back a few of my packages, causing some tests to > break (especially since I didn't have it master checked out for it, so I > wasn't expecting it to really change! I only tracked it down because of the > julia-users announcement). That's not Optim's fault, but an issue with the > package system for not making it explicit why it was occurring (at least it > didn't a month ago?). I think Pkg.update() tells you when a package is > rolled back, but not why. > > IIRC, I was really hoping that Pkg.status() would tell me whenever a > package was not at its highest version due to another package, and tell > me which package was doing that. For example, > > -CoolPkg 0.1 (Rolled back due to AwesomeFoo) > > Then it would be easy to see where I should checkout master, find how to > make them work together, and submit a pull request! But I don't know if > that would be difficult to implement. > > On Friday, July 22, 2016 at 7:24:30 PM UTC-7, Tony Kelman wrote: >> >> Maybe a useful function to write and submit to PkgDev would be go through >> all installed packages, check the METADATA requires file for all the >> installed versions and display a list of upper-bounded dependencies and >> which package is responsible for each. A little bit of code might go a long >> way in making this more discoverable. > >
