Create a new vcpkg helper port from CMake function like vcpkg_from_github, vcpkg_from_git, etc.

[theblackunknown]

I would like to start discussion about moving the following vcpkg functions into a vcpkg helper port:

• vcpkg_from_bitbucket
• vcpkg_from_git
• vcpkg_from_github
• vcpkg_from_gitlab
• vcpkg_from_sourceforge

In an enterprise environment, we may maintain several mirrors for a number of source code repository and I want to be able to override those implementation to redirect the checkout to those instead of the public URL hardcoded in vcpkg provided implementation [1].
Having those into a vcpkg helper port instead of vcpkg scripts means that we can now override/overlay and version those as needed, which strictly improve the current usability.

In a nutshell, I envision as the same refactoring which was done with the introduction of vcpkg-cmake and vcpkg-cmake-config and allow for someone to override/overlay those using a custom registry or overlay ports respectively.

I did search for similar discussions but did not find any, however I found one interesting bit that this idea may help formalize: #33480 (comment)

I am opening this as a discussion before diving into implementation, but happy to start implementing this is this sounds useful !

[1] It is sometimes configurable, for example in vcpkg_from_github where we can provide GITHUB_HOST and AUTHORIZATION_TOKEN but this is not flexible enough to implement my use case because sometimes REPO name differs, and it is more powerful to override vcpkg_from_github with custom logic than to go and change every port portfile.cmake we are interested in.

[Neumann-A]

I am also for vcpkg-download but you can already redirect the script folder to a custom one.

[theblackunknown]

vcpkg-download

Is this a suggestion for this new port helper name ?
I have no strong opinion on it so far, this sounds like a good name not sure if we should aim for some generic as generic as your suggestion or maybe one more focused on SCM checkout ?

For example, there is also vcpkg_download_distfile, vcpkg_download_sourceforge, which I did not take in account in my initial idea.

[theblackunknown]

you can already redirect the script folder to a custom one.

Probably but I find it less consistent with the registry approach where you can already compose and version your own take on what a port should be. (How do you even do this ?)
At least this is how I see why vcpkg-cmake and vcpkg-cmake-config were created rather than asking people to override their scripts folder.

[Neumann-A]

(How do you even do this ?)

Either by overwriting the functions from a triplet via an include or you simply use the builtin --x-scripts-root=<PATH>

Is this a suggestion for this new port helper name ?

Yes. The idea is to also add more functionality like reading data from a download.json and then just call the correct download function depending download.json. I don't see value in adding a port without adding new/better functionality to it which makes maintaing and updating ports easier.

[theblackunknown]

Either by overwriting the functions from a triplet via an include or you simply use the builtin --x-scripts-root=

Thanks I have missed this, but I still believe an helper port would be more useful :)

[theblackunknown]

Yes. The idea is to also add more functionality like reading data from a download.json and then just call the correct download function depending download.json. I don't see value in adding a port without adding new/better functionality to it which makes maintaing and updating ports easier.

Agreed ! Happy to have an helper port for all of those, but I would still try to get the ball rollin starting with just the SCM utilities and then we can improve the port later.