Automate vcpkg port update PRs after TA-Lib releases

[greenTableWork]

Hi maintainers — following recent maintainer feedback, I’d like to propose adding automation for vcpkg updates when a new TA-Lib release is published.

[mario4tier]

I did change the PR to merge into the dev branch. Will try it, and follow up with merging to main in the coming days.

May be (not sure yet, have to do my homework about the output of your script), we could next automate maintaining all the files needed in /dist (like done for windows installer, source tar ball etc...)... leaving submitting to vcpkg as an easy manual step.

[greenTableWork]

Thank you @mario4tier for the reviews. Maybe some context about vcpkg would help here.

vcpkg is basically a cmake wrapper for cmake to use. It downloads, builds and installs the binaries into a cache. So all the "distributions" happen on the user machine. Vcpkg downloads the ta-lib source repo from github.

For updating the configuration of ta-lib after release, vcpkg only needs the version number and the commit hash essentially to fetch the appropriate source code. It also takes cmake commands if need be but that is already configured in vcpkg.

PR above sets those things up. The script updates a vcpkg source repo, commits the changes and creates a PR if environment permits it.

Yes it's possible that cmake commands needed to build ta-lib might change enough that vcpkg can't handle it and that is not covered in the PR above.

[mario4tier]

@greenTableWork Thanks a lot, the clarifications were very helpful (and a big time saver to me).
This is very good for now and the instructions are clear.

I did update the release procedure (commit #94424a7 )

More automation?

Consider automating the "suggested next step", with may be a prompt before the commit + push toward microsoft/vcpkg.

If doing this, consider to:

• Verify that the script is running on the main branch and it is not a TA-Lib fork (look for verify_git_repo_original in utilities).
• The VERSION is not a "draft". This is because a new VERSION in main is not officially a release until published on github.
• Verify that there was not already a PR for this version.

The goal is to fool-proof against a "random person" mess things up, or avoid duplication if run more than once (say in the future from a faulty github automation).

Github CI?

Trying to decide if we should automate calling your script as part of a github action.

One obstacle would be the Personal Access Token. This might be prone to break because expiring etc... and need to figure out how to allow you and others to maintain this forever.

I think if we reach this point, I will have to do it first because of that permission stuff, so may be manual call to your script is still the best for now... still thinking.

[mario4tier]

FYI, expect it to be merged to main at some point this summer. For now we are working on a major refactoring related to Rust/Java code generation in the dev branch (which will not affect C and vcpkg) and I prefer to avoid cherry picking merges in meantime.

[greenTableWork]

Hey @mario4tier thanks for the feedback. I think we can consider adding release hooks but I doubt if it's ergonomic to have GithubCI.

One obstacle is, of course PAT tokens, as you described.

However GithubCI might ultimately need same parameters as the script to run the commit update, from a human. Please let me know if you can come up with an automation idea that can make your life better. Since I personally don't know what TA-Lib maintainers go through during a release. Happy to help if we can come up with a spec.

[mario4tier]

The script is now on the main branch:
https://github.com/TA-Lib/ta-lib/blob/main/scripts/post-release-vcpkg.py

(Will try next to use the AI agent for a recommendation on further automation)