Right now, if there are other packages restricting the version of the package you want to update, you can only find out if you manually try to specify a newer version with
]up [email protected]
I believe a warning that the user is not getting the newest available version should be given even if the version number is not explicitly specified, because the user's intent is probably simply to get the newest version. If an update can't be made, at least the user should be made aware of that because otherwise they'll wrongly assume they are up to date.
This should not apply to cases where only ]up without a specific package is used.
See pull request #1606
This should not apply to cases where only
]upwithout a specific package is used.
Even when running ]up, wouldn't it be useful to list all packages which could not be updated to the latest version? That would really help identifying problems, as people probably don't often update a single package manually.
With upper bounds now being common, if you have a hundred or so packages in your environment, it's basically guaranteed that some subset of your packages are going to be held back for some period of time. (At least, until most packages hit 1.x series.) If you warn automatically, you're essentially putting users in charge; developers will get a steady stream of bug reports, "I got this warning, fix it now!" But it might not be an emergency; the package likely works just fine with the older version, and the user may not need the absolute latest functionality.
I like the implementation in #1606; only users who explicitly ask will see the warnings. Presumably they have some reason to be so motivated, and hence it's more directed and less "useless bother."
Note I wasn't suggesting to print the list of packages blocking others: just a list of packages which have not been updated to their latest version. That way people could simply see whether they care or not. Also, only packages which have been manually added would be listed, not obscure dependencies that have been automatically installed (about which you probably don't care).
Maybe it would be useful when running ]up to summarize how many packages are completely up to date, and how many are blocked from major, minor, and patch releases. Because people might want to look into blocked major releases but not patch releases. Something like:
Updated 134 packages (110 up to date, 1 major, 3 minor, 20 patch releases restricted by version bounds.
And if something like a -v flag for verbose is added the whole list would be specified, so only on demand.
Even cooler, now that I think about it, would be to make use of the release notes that people put into their packages. It would be super convenient to display the release notes of a potentially available update, so the user can save the trip to the project's github page if it's not important to them.
Like:
]diff PackageXYZ
And then it prints the release notes since the last update
Almost dup of https://github.com/JuliaLang/Pkg.jl/issues/1655
Most helpful comment
With upper bounds now being common, if you have a hundred or so packages in your environment, it's basically guaranteed that some subset of your packages are going to be held back for some period of time. (At least, until most packages hit 1.x series.) If you warn automatically, you're essentially putting users in charge; developers will get a steady stream of bug reports, "I got this warning, fix it now!" But it might not be an emergency; the package likely works just fine with the older version, and the user may not need the absolute latest functionality.
I like the implementation in #1606; only users who explicitly ask will see the warnings. Presumably they have some reason to be so motivated, and hence it's more directed and less "useless bother."