The deeper problem though is: what if I want to use all the currently installed packages at the same time, but don’t want the downgraded versions of them? Say I want to use package A and B, and both have a dependency on C, but A requires some older version of C, and that prevents me from getting the latest version of B.
In some way the situation is a little like DDL hell on Windows in the early 90s: we can only ever have one version of a dependency installed and loaded at the same time in julia right now. I guess one way to “solve” this would be to start adding new versions of packages whenever there is a breaking change, i.e. when C introduced a breaking change it could have registered a new version C2. Terrible, of course, but that is what happened on Windows for things like the MS C runtime… Are there any thoughts around this, how this could be solved for julia? My guess is that these situations will only happen more often as the package eco-systems grows… From: [email protected] [mailto:[email protected]] On Behalf Of Stefan Karpinski Sent: Saturday, July 23, 2016 11:06 AM To: Julia Users <[email protected]> Subject: Re: [julia-users] Re: Which package downgrades other packages? 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] <mailto:[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.
