Special-casing packages which are git repos

[iboB]

I have an idea of adding more features to packages but it will be hard to impossible to implement for anything which is not a git repo.

ls-remote

By employing git ls-remote one can fetch a remote repo's tags without cloning (and in certain cases depending on the server configuration, even commit hashes)

After obtaining a list of the remote tags, one can collect the ones matching v<number>.<number>... to get the available versions which would allow these features (for git-based packages only):

• Adding a package with no version could fallback to the latest stable version instead of the latest commit in the default branch.
  • This can be reflected in the package lock.
  • With some clever arg parsing, if we can infer a version and name, then we can infer a source and the idiomatic way of adding packages can become something like CPMAddPackage(catchorg/Catch2) (detected as Catch2 from GitHub with the latest version-like tag)
• Version ranges for packages can be defined VERSION "> 1.2.3", VERSION "< 2.0.0", or ruby-style pessimistic matches VERSION "~> 1.2.3"

Non-shallow clones

Going deeper, if we have a non-shallow clone of a repo and we're talking about hashes as opposed to tags or versions, we can detect if a commit is an ancestor of another, and thus have some idea whether a package's (hash) revision is newer and potentially backwards compatible or older and potentially lacking features than another. Or maybe it's unrelated and dangerous. Thus more informative warnings or errors can be displayed if a package is referenced multiple times by hash

Distant future

This could also open up the path to deeper version-based dependency management, though this path is filled with backwards incompatibilities and pushing the limits of CMake. As of now I'm not even sure whether this is something we even want to pursue. One could argue that a project built with an intricate balance of interdependent packages is a bad idea and bad design and CPM shouldn't try to empower people to build it. Or, alternatively, one could say strict version-based package management is something which is adequate for another package manager, say "CPM-Heavy", which has bulkier syntax but more guarantees for errors and version consistency.

[TheLartians]

ls-remote

Huh I was thinking about possibilities to get releases using the GitHub API, but never actually came across the built-in git feature ls-remote! That is a great idea for a simple way to add new packages or update existing ones. One thing I'm not exactly sure about is how to distinguish between actual releases and pre-releases / nightly builds from the tag alone. Perhaps some research on popular projects can show if there are common patterns we can use.

I do think that to use such a feature we should require users to use a package-lock file though to prevent the bad practice of depend on moving version targets and builds might break overnight if a dependency add's a new update. Being able to automatically update package-lock dependencies to newest versions does make it much more attractive anyways.

About version ranges I'm quite the fan of npm's versioning syntax. This also is another step to more npm-like functionality, as first requested in #99.

Non-shallow clones, Distant future

That's definitely an interesting idea, but imo might be way out of the scope of a simple package manager. It does bring up the idea of adding support for "CPM.cmake Plugins" that could add special functionality.

E.g. we could support "hooks" where a user could register a callback that get's called each time CPMAddPackage is invoked. This would allow to extend CPM.cmake functionality without modifying the source and add the "history-check" as an optional extension.