helper command to check what third party upgrades are available

[andijcr]

I was thinking that it would be beneficial some sort of automatic check if one of the libs imported via cpm has a new version available.

Assuming this feature is available only for third parties that are imported via a semantic versioning git tag,
it would need to interact with git to pull tags, parse tags, and show some kind of nice message.

This opens the question of how to control what kind of update to show (only patch, minor, o major updates), and if this kind of behaviour has to be customizable by library or just global check is ok.

as of now, I'm thinking of a functionality that fires at configuration time if enabled by a function, something like
CPMEnableCheckUpdates( PATCH | MINOR | MAJOR)
does this make sense?
I should be able to write something, using CPM_PACKAGE_[library]_VERSION to decide what libraries to check

[TheLartians]

Hey, thanks for the suggestion, I can see how such a feature would be useful! One thing that comes to mind is that imo we usually don't care much about outdated dependencies (unless there is a severe bug). But when the time to update comes it would be super helpful to have a tool on-demand that queries for newer versions and notifies us about available updates.

Maybe this would be great to introduce as an additional CMake package / target that checks for available updates as (e.g. by calling cmake --build build --target cpm-check-for-updates), similar to Format.cmake.

As for the version scope, in general it varies on a dependency basis, which is why most package managers allow users to specify a range of acceptable versions per package. However, as CPM.cmake still requires the user to update dependencies manually, perhaps simply showing all available updates (patch, minor, major) may be enough for a first iteration.

[itavero]

Just wondering, have you thought about adding support for version ranges to CPM.cmake and what challenges does it impose?

I think it would be super useful, but I can imagine there will be a huge performance hit involved.
Not to mention that using a package lock would be mandatory to get a reproducible result.

[TheLartians]

I think it would be very useful!

As far as I can tell, there are two main challenges we need to implement for version ranges:

• Parse available versions on the remote server, e.g. by using git ls-remote --tags and resolve to the correct one according to the version range.
• Detecting version mismatches from the lockfile and resolving the new versions correctly on changes to version ranges. Also I think we need some more discussion on the lockfile format / usage / conventions, before it becomes an essential feature.

Both should hopefully be fairly straightforward to solve. However, a caveat is that CMake / CPM.cmake will still work imperatively, meaning that we discover and add dependencies as we go. This sets some limits on our resolution strategies and can make transitive dependency versions a bit messy.

[itavero]

I think the current mechanism for detecting "version mismatches" is still fine as long as users are aware of this limitation (which they already should be).

My expectation is that you probably want to use this functionality together with a lockfile that reflects both the version (range) required as well as the actual, specific version (e.g. tag) being used/included.
Only if CPMAddPackage is called with a version (range) that does not match the specific version being used, a warning/error should be given, I'd say.

[TheLartians]

(sharing here from a related comment in the issues)

@TheLavaBlock has implemented a clever solution in liblava using a update.py script. In this case there is an equivalent to a "lockfile" at cmake/version.cmake that the script is able to easily parse and update. I think it should be possible to implement a similar solution using our current package lock mechanism.