The way to do this would be to compute which packages' removal would allow another package to be upgraded.
On Sat, Jul 23, 2016 at 1:59 PM, Tony Kelman <[email protected]> wrote: > 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. >> >>
