Please, don't deprecate vcpkg_apply_patches()

[Arech]

Describe the issue

vcpkg_apply_patches() port function "has been deprecated in favor of the PATCHES argument to vcpkg_from_github() and similar functions.". When it's used by a port, it emits a warning.

The issue is, all vcpkg_from_*() functions aren't generic enough to cover all possible use-cases to fetch the code to compile. For example, neither vcpkg_from_git(), nor vcpkg_from_github() support fetching submodules of a repo, so a developer must resolve to using git manually. The same applies to other complex cases of using git or anything else to produce a local version of the source code. And there are cases when the obtained source code has to be patched.

I don't know if this applies to ports stored in the main vcpkg repo, however, this is definitely a major use-case for private repositories. We are using vcpkg internally in my company and removing vcpkg_apply_patches() would be a blocker for using vcpkg at all. Even deprecation of that feature makes decision makers start to think if they should proactively change approach to internal software distribution, before it's too late and it's broken.

"640kb of memory is not enough!" - you just can't cover all possible cases to fetch source code in a few simple small wrappers. Please don't restrict how vcpkg could be used.

Please, leave vcpkg_apply_patches() a normal supported standalone function.

Expected behavior
vcpkg_apply_patches() should be a normal non-deprecated fully supported standalone function available for port developers.

[Osyotr]

For example, neither vcpkg_from_git(), nor vcpkg_from_github() support fetching submodules of a repo, so a developer must resolve to using git manually.

You can also download submodules manually (using vcpkg_from_* functions) or make them vcpkg ports.

[Arech]

@Osyotr this isn't an option, as it requires to push unnecessary knowledge about source code internal structure into the port. Git already knows it and could and should take care of it.
The same applies to additional work of making vcpkg ports of things that aren't needed elsewhere.

And still - there could be millions of other ways of getting source code. Removing vcpkg_apply_patches() will break them for no reason.

[BillyONeal]

Deprecate in this context means "emit a warning and freeze ~forever in a block of ice" not that we intend to remove it: that would break previous versions of ports.

It remains true that vcpkg_apply_patches behaves badly in the presence of binary caching and/or --editable, and it is best to avoid it when possible, private registries or not.

[dg0yt]

binary caching and/or --editable asset caching and --editable

• vcpkg_from_git and git submodules can't use asset caching.
• --editable needs to consider all inputs to derive a unique source dir name.

[BillyONeal]

@dg0yt under --editable it's expected that the sources are manually edited so the input set is unknowable

[dg0yt]

@dg0yt under --editable it's expected that the sources are manually edited so the input set is unknowable

@BillyONeal I don't think this matters with regard to the deprecation of vcpkg_apply_patches. But --editable really stumbles over explicit, unconditional vcpkg_apply_patches.

This pattern could be seen for port crashpad until I updated it a few days ago. You could build once, but not again, with --editable.

[Arech]

@BillyONeal and @dg0yt , thank you guys for the perspective, that was helpful. I'm glad that this feature is at least not under a risk of sudden removal.
I didn't know about issues with caching for this specific function. Can you may be give me some pointers where to look for more details, so I could understand it better? I could read the source code, just not particularly sure where to start from..

[dg0yt]

vcpkg's asset caching is based on SHA512 sums of the asset blob. vcpkg_from_git doesn't have such a blob - It interacts directly with a remote git repo via the git binary.

There is an issue for it: #27858.
The task is to make a reproducible tarball from the result of the checkout - regardless of platform.