tools: extend vpm to support specifying git version tags when installing modules

[ttytm]

The change updates and extends VPM to install module versions based on git tags.

E.g. when installing modules

# VPM modules
v install publisher.module@v0.4.0
# From URLs
v install https://github.com/publisher/repository@v1.0.0

And when specifying dependencies in a v.mod file

Module {
	// ...
	dependencies: ['publisher.module@v0.6.0', 'https://github.com/publisher/repository@v1.0.0']
}

Will also create the base for some great followup features.

🤖 Generated by Copilot at fc08098

This pull request enhances the vpm tool with new features and tests for installing modules from various sources. It adds a new is_force option, a new is_external field, and a new InstallResult enum to improve the logic and user interface of the v install command. It also adds output assertions and version tag support to the existing and new test functions in dependency_test.v, install_test.v, and install_version_test.v.

🤖 Generated by Copilot at fc08098

• Add a new field is_external to the Module struct and use it to simplify the logic of installing modules from external URLs or VPM identifiers (link, link, link, link, link)
• Add a new enum InstallResult and use it to handle different outcomes of installing a module, such as installed, failed, or skipped (link, link, link)
• Add a new method confirm_install to the Module struct and a new function at_version to prompt the user to confirm the installation of a module if it is already installed with a different version (link)
• Add a new field is_force to the Settings struct and use it to allow the user to overwrite the existing installation of a module without confirmation (link, link)
• Modify the has_vmod function to take an install_path parameter and skip fetching the remote repository if the module is already installed and has a v.mod file (link, link)
• Modify the vpm_install_from_vcs function to check the VCS executable once and print the modules array for debugging (link)
• Modify the install method of the Module struct to print more verbose messages and handle specifying the version tag (link)
• Modify the expected output of the v install command in the test_install_from_git_url function to reflect the changes in the install method of the Module struct (link)
• Add assertions to check the output of the v install command in various test functions (link, link, link, link, link)
• Add a new file install_version_test.v with two new test functions to test the functionality of installing modules with specific version tags from VPM identifiers or external URLs (link)

[ttytm]

Updating the messages is part of adding a V styled version of prints that are similar to what a user would see when using cargo. Wanted to do it in a followup.

Thought of something like this:

[ttytm]

I couldn't find a vlang repo that is tagged and could be used.
So for identifiers of vlang repos it would be required that one gets a tag release.

Repos where it might fit:

• sdl , since it was mentioned installing a specific version will be useful.
• vab, is the only one that is available via vpm.vlang.io that has a tag available. But the tag is very old, e.g. the repo didn't have a v.mod file back then.
• vsl, has tagged releases on the repository but it's url on vpm.vlang.io is set to a fork. v install vsl does not install the same repository as v install https://github.com/vlang/vsl. The fork doesn't have tags.

[spytheman]

@larpon can we add a newer tag to vab?

[spytheman]

sdl , since it was mentioned installing a specific version will be useful

In SDL, we are using branches, not tags, because we are still patching things from time to time (when making things work with latest V, or to support/wrap APIs that were missed), and branches can be updated, and then git pull will get the new changes, unlike tags, that can not be updated easily, once published.

[spytheman]

@larpon, @ttytm, I've added a new tag https://github.com/vlang/vab/tree/0.4.0 .

[spytheman]

There is now a v.mod file in https://github.com/vlang/libsodium/ too, as well as
a tag there also https://github.com/vlang/libsodium/tree/0.2.1.

[ttytm]

sdl , since it was mentioned installing a specific version will be useful

In SDL, we are using branches, not tags, because we are still patching things from time to time (when making things work with latest V, or to support/wrap APIs that were missed), and branches can be updated, and then git pull will get the new changes, unlike tags, that can not be updated easily, once published.

Thanks @spytheman. I see. Installing a branch works as well. Gonna, add this to the tests cases then too.

v install sdl@2.0.9

So sdl version installs are covered @larpon.

I work something out to compare differences, so that a branch installation can be updated without needing to confirm or add a force flag. And eventually add installations of commit SHAs.