[vcpkg-tool] vcpkg-tool/main fails due to missing vcpkg-tools.json in vcpkg/master

[StarGate-One]

Describe the bug
A clear and concise description of what the bug is.
After latest commit Change tool metadata file format to JSON 1553 vcpkg errors out when attempting to install packages.

Environment

• OS: [e.g. Windows/Linux etc...]
  Windows Version [10.0.22631.4602]
• Compiler: revision
  Visual Studio Community 2022 Version: [17.12.3] VS Tools Version: [14.40.33807]
  Microsoft (R) C/C++ Optimizing Compiler Version [19.40.33817] for x64

To Reproduce
Steps to reproduce the behavior:
Using classic vcpkg mode.

1. ./vcpkg install [choose any port] --classic ...
2. See error Repro code when error: try_read_contents("D:\vcpkg\scripts\vcpkg-tools.json"): no such file or directory

Expected behavior
A clear and concise description of what you expected to happen.
Where do I get or can I create the vcpkg-tools.json file?

Failure logs
-(please attached failure logs)
No logs produced

Additional context
Add any other context about the problem here.
Note: I download the vcpkg-tool source and do a local compile.

/cc: @BillyONeal @vicroms @JavierMatosD

[autoantwort]

You have to wait for an official release or use the vcpkg-tools-json branch

[StarGate-One]

So should there be a vcpkg-tool vcpkg-tools-json branch as to keep both vcpkg/master and vcpkg-tool/main repos functional?

When ready for the official release both branches are then moved over to their respective master and main branches?

/cc: @AugP

Note: I worked around it by backing the change out of my local vcpkg-tool repo. Thanks again for all the hard work you guys do everyday.

[autoantwort]

The needed files are added to the vcpkg/master branch when needed (when a new vcpkg-tool release is created and the references version in vcpkg/master points to this new version)

I don't understand what problem do you have?

[StarGate-One]

The problem is as stated above. For those of us that download the current vcpkg-tool repo and compile/link to make our own vcpkg-tool binary no longer works with the current vcpkg repo.

Those who have a pre-compiled binary downloaded by the bootstrap scripts will work fine as they were built from the source before #1553 was committed to main, but there are many who always build vcpkg-tool from source for various reasons/local requirements.

[autoantwort]

Ok but what prevents you from simply using the source of the latest release?

[StarGate-One]

Do you mean the current vcpkg-tool binary or the current vcpkg-tool source?

The former nothing but local policy requirements or one of the Linux/BSD versions where there is no supplied precompiled binary, the latter the vcpkg-tool binary does not have a vcpkg-tools.json in the vcpkg repo in branch master resulting in the vcpkg binary exiting in error.

D:\vcpkg
->vcpkg install ada-url[tools]
Computing installation plan...
error: try_read_contents("D:\vcpkg\scripts\vcpkg-tools.json"): no such file or directory

As I noted to work around, I have reset my local vcpkg-tool repo to the commit 18a617c76fc0e9c18d87c3cc625ef1a4ebce269b which is before the vcpkg-tools.json changes were made in commit f3515102d0ff5f10a13c26ee8d6f2f1c2841e745 to vcpkg-tool repo.

I created this issue ticket to forewarn and/or help others who may find themselves in this same situation.

[autoantwort]

I mean the source of the latest vcpkg-tool release

[StarGate-One]

The latest vcpkg-tool repo source compiles and links fine.
Using vcpkg install [port] with it produces this error:

D:\vcpkg
->vcpkg install ada-url[tools]
Computing installation plan...
error: try_read_contents("D:\vcpkg\scripts\vcpkg-tools.json"): no such file or directory

I also found another work around was to copy the vcpkg-tools.json from the vcpkg-tools-json branch of vcpkg into the scripts directory and the error is not longer produced.

[dg0yt]

Not the latest source (HEAD) but the latest release (2024-12-09).

[StarGate-One]

I clone vcpkg-tool and then compile/link cmake/msbuild - so (HEAD) is used.

As stated, I have 2 different work arounds, so I'm fine now.

I just did not expect the main branch of vcpkg-tool to be unusable with the master branch of vcpkg.

I am closing this issue as the back and forth between us is not accomplishing anything.

[BillyONeal]

Sorry, I wanted to do a tool release quickly to ship this change together but I ran into a roadblock with some code signing changes that broke our release pipeline. Should be fixed in the next couple of days at the latest (with a new tool release)

[StarGate-One]

Hi @BillyONeal - thank you for all the hard work you and the others do everyday.

No worries, I understand, higher priorities, been there in the past .

I at first backed the change out and then thought maybe just having a legit vcpkg-tool.json would work, so after @autoantwort
mentioned there was a different branch I copied the one from the vcpkg[vcpkg-tool-json] branch and it seems to be working.

I never notice the other branches as I do a shallow branch clone of vcpkg/master and vcpkg-tool/main only - but I learned something here - check other branches regularly.

Thanks again

[BillyONeal]

I never notice the other branches as I do a shallow branch clone of vcpkg/master and vcpkg-tool/main only - but I learned something here - check other branches regularly.

This is the first time I can remember we left the tool repo and the registry repo out of sync for a while; normal procedure after any change looking like this is to immediately do a tool release to get them in sync again, which is why you haven't seen this before and in a perfect world, you would never see it. It's only because the release pipeline that mints tool releases broke in a way we only discovered after trying to mint a release that left it broken for a few days.

[dg0yt]

OTOH the tool repo has actual releases. The registry is just rolling with time-based tags, picking a new tool release every now and then.

[BillyONeal]

OTOH the tool repo has actual releases. The registry is just rolling with time-based tags, picking a new tool release every now and then.

Right, I mean we intend the registry to pick a tool release that works with it very shortly after a corresponding tool change is made. There would be some window where this problem was visible, but not more than a week under normal conditions as now.

[BillyONeal]

Well I got the bits to actually mint the release finally today, and 2025-01-10 existed for about 5 minutes before it failed the first smoke test:

Will keep you posted!