How to install specific version?

[HoLue]

Just to update everyone: Versioning is fully available and supports pinning specific library versions. Please open a new issue if you have further questions!

https://github.com/microsoft/vcpkg/blob/master/docs/users/versioning.md

Originally posted by @ras0219-msft in #1681 (comment)

[HoLue]

How can I install a specific version, for example I want to install zlib 1.2.9? How is the command?
vcpkg install zlib
will install the newest version, wouldn't it? So how can I do it?

[autoantwort]

I suggest reading the documentation: https://learn.microsoft.com/en-us/vcpkg/consume/lock-package-versions

[HoLue]

Well, I only find there how to create packages or to use them with cmake. Actually I don't use cmake. I just install a package via
vcpkg install xyz
and use it dierectly in Visual Studio c++ without cmake. I thought it is possible to install another verwion for example via something like
vcpkg install xyz -v 1.2.3.4
and then when compiling a project in Visual Studio this version is used.

[oneengineer]

Yeah, do something maintainer!

[ChilledCosmonaut]

Just to add to the discussion. I find it mildly infuriating that the feature set between classic mode and manifest mode is distributed so randomly..... On the one hand you can't force static inclusion with the manifest mode which you can with the classic mode, but you can't define the version in classic.... I would really appreciate that the feature sets get unified and you can do everything in one or the other

[autoantwort]

On the one hand you can't force static inclusion with the manifest mode

What do you mean by that?

[ChilledCosmonaut]

Sorry for the late reply. Especially the missing --head mode for manifest files or that you can define different behaviours like static and dynamic for library linking is a huge bummer. I mean it doesn't really affect the typical end user that much but especially if you are trying to setup your internal registry and want to test some production code with it, it gets really tedious. Which is annoying as you need basically two different ways to include libraries. One for in development ones and the other for the rest. And this does not even tackle the other issues that arise when you mix vcpkg if submodules or solutions alike. It happens regularly that you get duplicate dependencies and the build pipeline just throws out errors left and right.
This small paragraph might be off topic and presents thing harsher than they are, but the fact still holds true that vcpkg is lacking some (internal) dev/debugging features that would be very welcomed by people maintaining internal vcpkg registries for active development.

[autoantwort]

you can define different behaviors like static and dynamic for library linking

Do you mean the ability to install a package twice for different triplets in classic mode or something like https://learn.microsoft.com/en-us/vcpkg/users/triplets#per-port-customization to change the linkage of every package?

[ras0219-msft]

You will need to use our new manifest mode, which is very easy in Visual Studio! Simply add a vcpkg.json next to your solution file (in the root of your project) and follow the instructions under "MSBuild Integration": https://github.com/microsoft/vcpkg/blob/master/docs/users/manifests.md#msbuild-integration.

To pin specific versions, you'll need to use overrides:

{
    "dependencies": [ "xyz" ],
    "overrides": [
        { "name": "xyz", "version": "1.2.3.4" }
    ]
}

[autoantwort]

You can replace Visual Studio with cmake:
You will need to use our new manifest mode, which is very easy with CMake! Simply add a vcpkg.json next to your CMakeLists.txt file (in the root of your project) and follow the instructions under "CMake Integration": https://github.com/microsoft/vcpkg/blob/master/docs/users/manifests.md#cmake-integration.

To pin specific versions, you'll need to use overrides:

{
    "dependencies": [ "xyz" ],
    "overrides": [
        { "name": "xyz", "version": "1.2.3.4" }
    ]
}

Or if you don't use cmake, simply run vcpkg install

[Raffaello]

this doesn't work.

\vcpkg.json was rejected because it uses "overrides" and does not have a "builtin-baseline".

it looks like that is forced to have something like this line as extra:

"builtin-baseline": "a14a6bcb27287e3ec138dba1b948a0cdbc337a3a",

and that line is absolutely something not wanted in a "simple" manifest file to specify dependencies and pin version to it.

[Raffaello]

not sure what that hash string is refererring to anyway..

[Raffaello]

i see:

 builtin-baseline                The baseline references a commit within the vcpkg repository that
                                  establishes a minimum version on every dependency in the graph.
                                  For example, if no other constraints are specified (directly or
                                  transitively), then the version will resolve to the baseline of
                                  the top level manifest. Baselines of transitive dependencies are
                                  ignored.
                                  
                                  

can't have just a default "auto" value and referencing to the latest commit ? and if specified can be overridden instead?
as i think is quite annoying managing a commit hash of the package manager in the projects that are using it...

[autoantwort]

To add an initial "builtin-baseline", use vcpkg x-update-baseline --add-initial-baseline. To update baselines in a manifest, use vcpkg x-update-baseline.

can't have just a default "auto" value and referencing to the latest commit ?

That would be easier.

[aSemy]

Unfortunately 'manifest mode' is not fully implemented (for example, it's incompatible with vcpkg export #17873), so setting versions with vcpkg.json is not not a workaround.

[kzhdev]

How to install a specific version in the command line? I just want to install a specific version of protobuf in vcpkg's root installed folder

[autoantwort]

How to install a specific version in the command line?

You will need to use manifest mode or checkout vcpkg at the right version

[HoLue]

How to install a specific version in the command line?

You will need to use manifest mode or checkout vcpkg at the right version

But how can I checkout a specific version in vcpkg?

[autoantwort]

You search the commit with the specific version and then do git checkout .... But I really recommend using manifest mode

[HoLue]

You search the commit with the specific version and then do git checkout .... But I really recommend using manifest mode

git checkout? I want to use a specific package version, e.g. OpenCV 4.5.3 !

[kzhdev]

How do I know which version of vcpkg contains the package version what I want?

[kzhdev]

If vcpkg supports versioning in manifest mode why can't it support in the command line mode?

[bluntcoder]

Using a JSON manifest file, although welcomed by some, is not intuitive - people expect to be able to install packages from the command line. That's how most package managers work.

[autoantwort]

There is vcpkg add port .... For example vcpkg add port 'libpng[core]'

[adrienbernede]

Just to add a practical scenario:
I’m using Github Actions, installing dependencies for my code with different OSes, including Windows.

In each build, I want to pinpoint the version of the dependencies, and I want to cache those dependencies by version.
That way, I can be sure the version will not change in my CI without me approving it, and I can parametrize the cache key with the version so that I cache-miss if I change the version.

Now, this is a one-line operation if I can do:
vcpkg insatll my-dep@${MY-DEP_VERSION}

This is a multi-line-what-the-heck-I-need-to-generate-a-json-file-on-the-fly-just-to-pass-the-version step with the manifest mode. (with a shell language I don’t know, by the way).

Note: versioning the manifest in my repo could work, but is much less transparent regarding the versions used in CI, which is my simple and only goal.

Thanks

[autoantwort]

This is a multi-line-what-the-heck-I-need-to-generate-a-json-file-on-the-fly-just-to-pass-the-version step with the manifest mode.

The intended way is that you have a vcpkg.json file in your repo that describes your dependencies and in the ci you only call vcpkg install (or this is done automatically by the buildsystem integration).

[adrienbernede]

Except I may want to try different set of dependencies and also see clearly the version of the dependencies I use.

This is also about doing things the same way on all operating systems instead of having a dedicated scenario for one of them. In GitHub Actions, I can control the dependency version with a matrix parameter, but it doesn't work with the manifest workflow. This means more code to add and maintain.

[adrienbernede]

Don’t take me wrong, a "manifest" is great in many situations, just like an "environment" in Spack. But a command like way to control things is often necessary too.

[veteri]

This has to be a joke. If reading a json file is enough for it to install a specific version, the functionality is already there.
Just make it into a command...

[rnwhitehead]

The command is definitely required as well as the manifest mode. For example, manifest mode works really badly in the case of a docker script: If you have lines like:

ADD ./src src
CMAKE ....

then if you change the source code at all, the dockerfile has to run all the lines including the build - which means that all the dependencies are rebuilt, every time you change the code at all, which is a nightmare during development.
Much better would be:

RUN vcpkg install dependence=1.2.3
ADD ./src src
CMAKE ....

but you can't do that.

I've also had lots of problems with some dependencies, such as google's cloud APIs - vcpkg works by remembering the git hash of the repo at each version (why? why not the tag??) and it seems that google somehow keep changing the hashes so the vcpkg build constantly breaks.

[Neumann-A]

That command is just:

vcpkg install 
         --triplet <triplet>
         --vcpkg-root <vcpkg-root-to-use (optional)>
         --x-wait-for-lock (no clue what this does; probably also optional)
         --x-manifest-root=<dir_containing_vcpkg_json_or_vcpkg_configuration_json>
         --x-install-root=<dir_to_install_to>
         <more_optional_options>

nothing scary about this.

[rnwhitehead]

That command is just:

vcpkg install 
         --triplet <triplet>
         --vcpkg-root <vcpkg-root-to-use (optional)>
         --x-wait-for-lock (no clue what this does; probably also optional)
         --x-manifest-root=<dir_containing_vcpkg_json_or_vcpkg_configuration_json>
         --x-install-root=<dir_to_install_to>
         <more_optional_options>

nothing scary about this.

@Neumann-A But we are told that there is no way to install a particular version (i.e. to pin a version) using vcpkg install, the only way is using manifest mode (see @ras0219-msft above). That's what we are all moaning about. How does it manage it?

[Neumann-A]

No you where moaning about not being able to execute vcpkg without being part of the cmake build (that was the main point of your docker example). You still need to have a manifest.
With --x-manifest-root=<path> you are able to control where vcpkg looks for the manifest and with --x-install-root=<path> you can tell vcpkg where to install stuff to. (Just make sure that vcpkg.cmake also knows about the latter by setting VCPKG_INSTALLED_DIR correctly)

[rnwhitehead]

@Neumann-A This page is all about "How to install a specific version? #25622" - that's its title. People asked how to do that without using manifest mode, and were told by @HoLue, @autoantwort and @ras0219-msft who appear to be a Microsoft employees that it could not be done. Many people have complained that this is inconvenient and stupid, and Microsoft appear to not be listening.
My point was to show an example of a use case where being able to pin a version using vcpkg install would be more convenient than using manifest mode: in a docker container, it makes more sense to install dependencies explicitly rather than have them installed as part of a build command, because of the way docker caches the results of each command.
You have definitely advanced the discussion, thank you - I had not seen that code you pasted, I would not have known where to look.
I tried getting vcpkg to install a directory that contained only a manifest file and it would not do it, so I'm still not sure what to do; but the undocumented --x-manifest-root may be what we all needed.

[Neumann-A]

Many people have complained that this is inconvenient and stupid

There is a reason for it. Lets assume there would be a command like vcpkg install vtk=8.2. It install vtk 8.2. VTK has a lot of dependencies. Which version of the dependencies should be installed? Would you expect it to be not broken? (It will be horribly broken which updated deps). The only thing vcpkg could offer is a vcpkg install somedep --baseline=<baselineref> everything else would be too complex. That is why manifest mode is the only sane way to go

but the undocumented --x-manifest-root may be what we all needed.

https://github.com/microsoft/vcpkg/blob/master/docs/commands/common-options.md#--x-manifest-rootpath

Maybe vcpkg just needs some explicit docs on how to invoke manifest manually without any integration

[brinkqiang]

vcpkg install libxxx=1.2.3
vcpkg install libxxx -v 1.2.3
vcpkg install [email protected]
No matter which of the above methods is used, it is consistent with first principles. That is human nature. instead of
vcpkg install libxxx
./mysrc/vcpkg.json
I went to install libxxx with nothing to do with mysrc.

[Raffaello]

actually it should be without the vcpkg install libxxx
as the vcpkg.json is loaded as part of the CMAKE TOOL CHAIN and the pacakges are downloaded if missing or if previously downloaded refer to those. basically vcpkcg standalong installation provide the local registry cache of the library that you need.
in this way even if it might be counter intuitive.
it is better to have the repository itself containing its own dependency and its own version, plust the commit hash guarantee a deterministic build as something might have changed in the latest version.
instead if you can install different version in your global vcpkg installation if you have N projects running N different version of libxxx is just more complicated as when you don't specificy the version which one should use? latest one installed locally? yeah maybe right..

anyway, what i am simply trying to say is:
It is not so bad after all, need to go thinking about it throught.

the point is forcing now to use vcpkg,json and it should be also recommended so you code can have the exact dependency, with that exact vcpkg version you have use to build, so in 1y time if no one touches it mostly guarantee to still build, when instead this kind of C/C++ projects are generally not compiling anymore after 1y of no maintanance as just something that it was depending on has changed and it was not fixed, vcpkg.json looks like it address this too instead.

[brinkqiang]

actually it should be without the vcpkg install libxxx as the vcpkg.json is loaded as part of the CMAKE TOOL CHAIN and the pacakges are downloaded if missing or if previously downloaded refer to those. basically vcpkcg standalong installation provide the local registry cache of the library that you need. in this way even if it might be counter intuitive. it is better to have the repository itself containing its own dependency and its own version, plust the commit hash guarantee a deterministic build as something might have changed in the latest version. instead if you can install different version in your global vcpkg installation if you have N projects running N different version of libxxx is just more complicated as when you don't specificy the version which one should use? latest one installed locally? yeah maybe right..

anyway, what i am simply trying to say is: It is not so bad after all, need to go thinking about it throught.

the point is forcing now to use vcpkg,json and it should be also recommended so you code can have the exact dependency, with that exact vcpkg version you have use to build, so in 1y time if no one touches it mostly guarantee to still build, when instead this kind of C/C++ projects are generally not compiling anymore after 1y of no maintanance as just something that it was depending on has changed and it was not fixed, vcpkg.json looks like it address this too instead.

You're right, so on the other hand, what is the loss in implementing this function. Is it complicated? If other users don't have that need, and you provide this feature, what do they lose. I'll just say we have this need and it's strong and I'm sure it's not just me.

[Raffaello]

not sure what is this feauter you are referring too, as the discussion topic is about to "How to install specific version?" That can be done with vcpkg.json in your project.

if you are referring how to do it through the CLI, I think it is going to a rabbit hole and philosofical discussion about best practices:
if you have global and your project refer to a global vcpkg installation with a fixed version sooner or later is going to be broken for even just a change in the vcpkg executable itself or in the repository etc.

as the vcpkg cli and installing pacakges should be considered a global context of operation, it can be done? yes, but why when it is best to have a vcpkg.json that locally address also the vcpkg pacakge version itself? and it is portable?

now i give you the example why cannot be implemented, or it is discuraged to implement it:

so if we are working on a project, or a team is working on the same project, every team member has to install vcpkg and manually (or through a script provided with the repo let say) install the dependencies that the repository is using for it. or otherwise you have to documented somewhere etc.
This is not feasible: if you updaet a dependency, i have to update my local dependency etc... vcpkg.json will do that automatically and it will also track the dependency version change as it is let say git committed file.
This should be already enough in my perspective.

But furthermore there is another problem:
let say, we are working togheter in the Project A, using libA v1.0
i am also working on a Project B, that unfortunately is using the same libA but v2.0

vcpkg if it allows to install versions it should also allow to install multiple different versions.
otherwise i should clone another vcpkg like if it is a different workspace and install in vcpkg2 folder the libA v2.0, that can be a workaround, but vcpkg is design to be 1 instance globally mostly not to be workspaced yet at least.

Also if it would be possible to install differnt multiple version of the same lib:
Here using vcpkg to install in is local folder libA v1.0 and libA v2.0 let say they will do like namespace the version first like /installed/v1.0/libA and /installed/v2.0/libA when you want to update you have also to create a --target-soure-version as if we decide to use libA v1.1 how can i just upgrade libA1.0 to 1.1? ok it can be done with installing v1.1 and removing v1.0 manually in 2 operation, but again, the uninstall also have to provide the version to uninstall. And you have to manually referencing in your project, or change the VCPKG toolchaing file also to accomodate this.

all this kind of extra work and possible code execution are not worthing doing it when you can simply have a vcpkg.json that it will also address the issue of working in a team and in multiple projects using the same library already, plus is tracking the vcpkg version.

Finally, global installation of whatever package manager in the world, doesnt allow to have 2 same dependecy available at the same time genrally, but it will just update the version most of the time, otherwise must implement a context switch to enable 1 and disable the other. Besides in this case as it could be considered only a local repository of libraries it could be done anyway, but it looks just like an over complication that is not needed.
As also when working in team you still have to somehow address a way to use the same vcpkg version to all the team members and to have repeatiable builds. etc etc..
so i hope this can help clarify why it would be better not to having that feature. :)

[rnwhitehead]

Yes the documentation would be very welcome. What we’re asking for with pinned versions is what tools like apt, anaconda and the Python package system do. Yes it has to cope with sub-dependencies and pinning and the fact that this can cause impossible situations. Otherwise it’s not a package system. From: Alexander Neumann ***@***.***> Sent: 27 October 2022 16:04 To: microsoft/vcpkg ***@***.***> Cc: Whitehead, Richard ***@***.***>; Comment ***@***.***> Subject: Re: [microsoft/vcpkg] How to install specific version? (Discussion #25622) [External Email] Many people have complained that this is inconvenient and stupid There is a reason for it. Lets assume there would be a command like vcpkg install vtk=8.2. It install vtk 8.2. VTK has a lot of dependencies. Which version of the dependencies should be installed? Would you expect it to be not broken? (It will be horribly broken which updated deps). The only thing vcpkg could offer is a vcpkg install somedep --baseline=<baselineref> everything else would be too complex. That is why manifest mode is the only sane way to go but the undocumented --x-manifest-root may be what we all needed. https://github.com/microsoft/vcpkg/blob/master/docs/commands/common-options.md#--x-manifest-rootpath<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_microsoft_vcpkg_blob_master_docs_commands_common-2Doptions.md-23-2D-2Dx-2Dmanifest-2Drootpath&d=DwMCaQ&c=Qwsh1H-X9ypOoLLEcAIltRyC0Dw0FG3Mmyd56ahml5w&r=w6ludjNtDQpNasrV7-vv8UaUPqkFSZ8tefXB_suiJPM&m=3udVCtu7vqyU_ptzAMKuJY-K4XWCI5xVeK0-siuWNDeQoBOfFjLhKusjrE-Eq9VI&s=lnFDN3tYiay3fxsq4e1GMut1gFstHzKnCtMuq2UUJuE&e=> Maybe vcpkg just needs some explicit docs on how to invoke manifest manually without any integration — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_microsoft_vcpkg_discussions_25622-23discussioncomment-2D3983073&d=DwMCaQ&c=Qwsh1H-X9ypOoLLEcAIltRyC0Dw0FG3Mmyd56ahml5w&r=w6ludjNtDQpNasrV7-vv8UaUPqkFSZ8tefXB_suiJPM&m=3udVCtu7vqyU_ptzAMKuJY-K4XWCI5xVeK0-siuWNDeQoBOfFjLhKusjrE-Eq9VI&s=ZlNr94_G2EUKcV4wv2QqGfP4LU53AOAd0vieiuZxTMo&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AUPE7CVQV5Q5NY6WROHSRD3WFKKWNANCNFSM52755FVQ&d=DwMCaQ&c=Qwsh1H-X9ypOoLLEcAIltRyC0Dw0FG3Mmyd56ahml5w&r=w6ludjNtDQpNasrV7-vv8UaUPqkFSZ8tefXB_suiJPM&m=3udVCtu7vqyU_ptzAMKuJY-K4XWCI5xVeK0-siuWNDeQoBOfFjLhKusjrE-Eq9VI&s=VkcfFGFrSp7NlAxYa9EsO7kZgyQ3P3kwemcVmat8XYk&e=>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

…

________________________________ - CONFIDENTIAL- This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.

[erikhugintech]

Maybe vcpkg just needs some explicit docs

vcpkg needs to have a simple solution for a simple need. I need a specific version of a package installed globally for a CI system. I do not want to deal with manifest files and git commit hashes and reading scattered docs and right-clicking in IDEs on a headless machine. Just give me a --version argument and then fail the install if it can't resolve - like EVERY OTHER PACKAGE MANAGER IN THE WORLD. Right now, it's easier to automate downloading and building myself, and that's not really your goal with vcpkg is it?

[rnwhitehead]

I'm going to have one final attempt to get through to Microsoft on this, and then give up. I've already stopped using vcpkg because of this and one other issue so I'm doing this to try to help Microsoft improve their offering.

1. Sometimes you need to pin the version of a dependency. For example, in a medical product, it is important that you can rebuild that exact version of the product in the future; if you need to make a small fix, it is important that you can make only that change, and not "accidentally" change other things. This isn't a nice-to-have, it's a legal requirement stemming from the medical device regulations. In other projects it is often good practice to pin dependencies, and sometimes necessary because the latest change to some dependency has some breaking API or functionality change which you don't want. We need pinning.
2. There are very sensible use cases where you want to install the dependencies separately to, or completely apart from, building the code. An example is a complex project where you want several programs to be built with the exact same (pinned) dependencies, it makes sense to avoid duplication. Another is in a docker build, where the docker caching mechanism means that every time you rebuild the code, vcpkg would rebuild all the dependencies unless the dependency build is done before the source code import. A third example is when providing a set of package installers that can be used on multiple platforms for multiple projects. A fourth example is when you want to do a one-time system-level installation to match some hardware, for example installing CUDA. There are many examples where it is sensible and we don't need to be told that we are wrong on this. Trust me, I've been doing this 40 years.
3. vcpkg clearly is clever enough to pin dependencies and it has the install-only option - it covers points 1 and 2. But for some reason, you cannot use these two functions at the same time. You can install dependencies explicitly from the command line without building code, but then you cannot pin; or you can install when building code, in which case you can pin. But you can't install dependencies using the command line and pin. If you could just pass the json file through to the command-line install then it would be solved. But you can't.
4. Any argument that it is somehow harder to cope with dependency pinning when done from the command line than when the same information is passed in a json file is surely nonsense.
5. All other mature package managers provide this. I can do apt install libopencv-dev=3.2.0 or apt-get satisfy "cmake-data (>= ${CMAKE_VERSION}), cmake (>= ${CMAKE_VERSION})"
6. Yes this can result in complex situations, including conflicts with existing or specified libraries in the target location (user and/or or system libraries). But if vcpkg can cope with this when using a json file, surely it can cope with the same information passed on the command line.

Ok that's it. I give up now.

[brinkqiang]

p.s. also if you have the vcpkg.json and you a code source repositry, for e.g. git, you have always a potential buildable project even if you go back in history of 1 year. without changing anything, as it is all fixed in the vcpkg.json file that you commit, so you also are tracking changes of your dependencies and pacakge manager version too..

If vcpkg install [email protected]
I can write an install.sh in it myself.
vcpkg install [email protected]
vcpkg install [email protected]
vcpkg install [email protected]
can achieve the same effect

Can you understand what we want?

[Raffaello]

@brinkqiang
as i have replied to another thread already in more details, but
try to summerize it again,
doing install.sh at that point you can use vcpkj.json as you are just reinventing the wheel.

you are not considering that he project is shared among different team members and each of the team member must have is own installation of vcpkg and the same version as well.
and not considerinng that you are working on multiple projects using the same liba but with different versions for each project.

anyway.

[veteri]

You can install dependencies explicitly from the command line without building code, but then you cannot pin; or you can install when building code, in which case you can pin. <...>. If you could just pass the json file through to the command-line install then it would be solved.

This statement is simply not true. You can pin on the command line using manifest mode as stated in #25622 (reply in thread). You cannot pass the file directly but you can pass the directory of the file via --x-manifest-root=<path_where_your_manifest_lives>. The reason it is not a file but a directory is simply because there are two files (vcpkg.json and vcpkg-configuration.json) which control manifest behavior.

So clearly, the problem is already solved.

Any argument that it is somehow harder to cope with dependency pinning when done from the command line than when the same information is passed in a json file is surely nonsense.
All other mature package managers provide this. I can do apt install libopencv-dev=3.2.0 or apt-get satisfy "cmake-data (>= CMAKEVERSION),cmake(>={CMAKE_VERSION})"
Yes this can result in complex situations, including conflicts with existing or specified libraries in the target location (user and/or or system libraries). But if vcpkg can cope with this when using a json file, surely it can cope with the same information passed on the command line.

If you want this implement it. vcpkg-tool is open source.... but from my personal point of view this is just complaining that vcpkg doesn't do it the way you would like although it already has the required functionality for your use case. vcpkg could certainly implement a command like: vcpkg install package1>=<version1> --baseline=<commitid1> but what happens to the installed tree if the user then uses vcpkg install package2>=<version2> --baseline=<commitid2> ? Require a rebuild of package1 with the new baseline, which version gets installed for it, if the new minimum moved up? If you add more baselines and packages the behavior gets more and more complex and less and less transparent for the user what is actually in the installed tree. As such having a manifest file, with a well defined baseline and all versions of the dependencies setup from the get go gives the user a transparent view on what will be installed.

Basically

vcpkg install package1>=<version1> --baseline=<commitid1>
(should vcpkg clean in between? That is not how vcpkg in classic mode currently works. So would require a quite big change of current behavior although a lot of people actually like the current classic behavior)
vcpkg install package2>=<version2> --baseline=<commitid2>
vcpkg install package3>=<version3> --baseline=<commitid3>

What will/should the end result be? Probably nobody knows. In addition to that vcpkg is not transactional while upgrading so this will clearly break users if something fails in-between.

while

vcpkg install --x-manifest-root=<manifest_dir1> (might need other --options to actually work; this is just an example.)
(manifest changed -> delete all -> start at 0)
vcpkg install --x-manifest-root=<manifest_dir2>

Clearly gives you what was specified at manifest_dir2 according to the versioning rules mentioned here: https://devblogs.microsoft.com/cppblog/take-control-of-your-vcpkg-dependencies-with-versioning-support/

TL;DR: Wanting something and understanding why it doesn't exist are two very different topics ;) Also problem is already solved.

Software is for users. If most users tell you they expected X or prefer X over Y, AND it exist in every other packet manager then ask yourself why you're still arguing against the users. It doesn't matter if the problem is solved already if the solution has terrible user experience.
Software should be fun and intuitive to use.

[brinkqiang]

@brinkqiang as i have replied to another thread already in more details, but try to summerize it again, doing install.sh at that point you can use vcpkj.json as you are just reinventing the wheel.

you are not considering that he project is shared among different team members and each of the team member must have is own installation of vcpkg and the same version as well. and not considerinng that you are working on multiple projects using the same liba but with different versions for each project.

anyway.

I can't compliment your understanding. As I said before, you can keep the vcpkg.json function. But don't influence others to have other options. Because you don't even know what I'm thinking about.

[Raffaello]

@brinkqiang as i have replied to another thread already in more details, but try to summerize it again, doing install.sh at that point you can use vcpkj.json as you are just reinventing the wheel.
you are not considering that he project is shared among different team members and each of the team member must have is own installation of vcpkg and the same version as well. and not considerinng that you are working on multiple projects using the same liba but with different versions for each project.
anyway.

I can't compliment your understanding. As I said before, you can keep the vcpkg.json function. But don't influence others to have other options. Because you don't even know what I'm thinking about.

it is a different context a vcpk.json to a cli global installation of a library.
the point that you are making is: you are telling that the right solution is to use vcpkg.json, but i don't want to use it and i want an equivalent solution implemented through the cli command.
I agree, nothing better that if there was also the cli version for it.
i am keeping saying: meanwhile that feature is not ready, the altearnative eventually is to use vcpkg.json to achieve the wanted result.

[Ou7law007]

Why is it too difficult to implement. There's literally no documentations on how to do it especially if no specific project is involved.
pip, apt, npm all support this and the functionality is there anyway...

[mister-good-deal]

I went from a c++ websocket lib that do not use any build system other than a hand written makefile to "well OK let's install vcpkg and install the lib with it to ease my building cross compiling env" to "wtf I cannot install a lib with vcpkg by command line with a specific version without writing a JSON file" to "git reset --hard && shutdown".

[Zipdox2]

I went from "I'll try to build my application natively on Windows" to "fuck it I'm not wasting any more time on Windows".

[Ou7law007]

Compiling the library on my own was much easier that waiting for 6 more years. It's just too difficult for Microsoft to implement an entire new command for an existing functionality.

[FrankLiu-OTOY]

so many discussions.
BUT what is the right way to install a specific version of a dependency?

[aSemy]

1. Checkout vcpkg

   To be reproducible, I check out a specific release by specifying the git tag 2023.02.24

   git clone --depth 1 -b 2023.02.24 --single-branch https://github.com/microsoft/vcpkg.git vcpkg

2. Build the vcpkg project

   cd vcpkg
   ./bootstrap-vcpkg.sh

3. Create a vcpkg.json file in the vcpkg directory. It must contain the library you want to build, as well as its dependencies, and the version override.

   For example, if I want to build RocksDB

   1. find RocksDB's dependencies in the existing rocksdb/vcpkg.json.
   2. set the RocksDB version I want to use in the overrides section.

   Since I'm running on CI/CD, I use a bash command to create vcpkg.json:

   ROCKSDB_VERSION = 7.8.3
   
   cat <<EOT >> vcpkg.json
   {
     "dependencies": [
       "rocksdb",
       "zstd",
       "zlib",
       "snappy",
       "lz4",
       "bzip2"
     ],
     "overrides": [
       { "name": "rocksdb", "version": "${ROCKSDB_VERSION}" }
     ]
   }
   EOT

4. I then have to tell vcpkg about the new vcpkg.json using vcpkg x-update-baseline

   ./vcpkg x-update-baseline --add-initial-baseline

5. Finally I can install my library

   ./vcpkg install

Yes, this is too complicated and confusing and undocumented and I wish it was better.

[netcorefan1]

@aSemy I'm not sure if I have understood well the whole process, but do you think that something like that could be adapted to solve my problem ? I need two versions of the same package (one compiled with no change and the other one compiled with a custom flag) and the ability to override a specific dependency with one of those twos, but if all you need is just one package specific version, wouldn't be easier to combine an overlay port with an overlay triplet?

[thegoodtgg]

A CMake way to implement the function

Provide a vcpkg.json.in

{
  "dependencies": [
    "rocksdb",
    "zstd",
    "zlib",
    "snappy",
    "lz4",
    "bzip2"
  ],
  "overrides": [
    { "name": "rocksdb", "version": "${ROCKSDB_VERSION}" }
  ]
}

Create CMakeLists.txt

set(ROCKSDB_VERSION "7.8.3" CACHE "Specify RocksDB version")
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/vcpkg.json.in ${CMAKE_CURRENT_SOURCE_DIR}/vcpkg.json @ONLY)

project(Example)

run cmake command

cmake -B build -G "Visual Studio 16 2019" -DROCKSDB_VERSION="Another version"  -DCMAKE_TOOLCHAIN_FILE="" .

[heheda123123]

[dg0yt]

I don't see what this gains w.r.t. to manifest mode.
And which version of vcpkg zlib will vcpkg libpng be built with?

[Zipdox2]

I am not going to change my build system, and I'm definitely not going to specify a particular package manager with my build system. A package manager SHOULD NOT be integrated with the build system in C. Microsoft should develop a decent package manager that allows existing build systems to find the installed packages like on Linux, BSD and OSX. All GNU/Linux distros and BSDs have this, and OSX has homebrew and macports. I feel like Microsoft is intentionally sabotaging compatibility to coerce developers towards using their proprietary Windows-only libraries and development tools. But I'm gonna go Hanlon's razor on this one: "Never attribute to malice that which is adequately explained by stupidity."

[DougRogers]

I have been a Windows developer for a long time. Here is my take.

vcpkg should manage all versioning on the command line. Period.

I'm sure there are ramifications to how this can be implemented "under the hood", but to the developer, it should be simple to use. No external dependency should be introduced.

Here is my proposal:
vcpkg already has dependencies, so it should be feasible to have a "build forest", that contains multiple build trees. Each build tree would have a specific version and all its dependencies. The root build tree would have the current version of all installed packages. If an older version of a library was requested, a new build tree would be created for that version and all its dependencies.

It would be then a matter of choosing the correct libraries from the build trees.

[wepiotrek]

1. Go to your vcpkg directory and execute: git log and copy the latest git commit hash (where is your HEAD),
2. add/create the following lines in vcpkg.json in your project root directory (where xyz is your dependency):

{
    "$schema": "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
    "dependencies": [ "xyz" ],
    "builtin-baseline": "(commit hash from step 1)",
    "overrides": [
        { "name": "xyz", "version": "1.2.3.4" }
    ]
}

3. Do the following steps:

• when you are using Visual Studio right click on your project > Properties > vcpkg > Use Vcpkg Dependencies: True
• when you are using cli just .\vcpkg install --x-wait-for-lock --triplet "(platform eg. x64-windows)" --vcpkg-root "(vcpkg dir)" "--x-manifest-root=(project dir)" "--x-install-root=(project dir)\vcpkg_installed\(platform)"

[adrienbernede]

Thank you. I just feel like you are starting a new debate loop here.

It is understood that, using a manifest file, one can install a specific version (provided that it was not removed in the current commit). And your answer seems complete and practical to answer the question as worded initially.

However, I’ll just mention my comment above: #25622 (reply in thread)
We often need more flexibility.

[Raffaello]

you can have a .ci/ (or whatever) folder in your repo containing vcpkg manifest file to copy over the original manifest file for CI purporses and that's done.

e.g.

.ci/vcpkg_libv1.json
.ci/vcpkg_libv1.2.json

## simple usage is to copy over the file based on a condition (ENV?) or so on...
cp .ci/vcpkg_libv1.json vcpkg.json

[adrienbernede]

@Raffaello that’s true, and not too bad I guess.

I will mention that I understand that the use of a manifest to specify a vcpkg commit since a package version could have been removed from the current one. It remains that the "tension" in this conversion is because of the non-alignment of vcpkg with other package managers in terms of command line features.

In my opinion, @wepiotrek answer and the conversion below, is a decent answer for the initial question. The debate, if needed be, should happen elsewhere.

Thank you.

[adrienbernede]

@aSemy answer is also valuable:

#25622 (reply in thread)

[erikhugintech]

How about you just let us pass a version on commandline, and then fail if it can't be installed? Why does it have to be complicated when the needs are simple?

[frederick-brier]

Same problem. I have skimmed this whole conversation, googling terms, and still don't understand why manifest mode requires a builtin-baseline. Why isn't using the vcpkg.json equivalent to the vcpkg command line passing the version? Why is the builtin-baseline required in the vcpkg.json? The builtin-baseline is redundant to the the version number. If you can't find the git tag with the version number, just FAIL. In trying to set up a CI with cmake, this is very frustrating.

[autoantwort]

The baseline freezes a set of versions (They are tested in ci to work together). You can use version>= to request a newer version or version overrides to request a specific version.

[Filoppi]

@autoantwort then why is the documentation so unclear and confusing, saying that it sets the version floor :D?
Am I the only one that expects documentation to be written for dummies?

[adrienbernede]

@Filoppi "version floor" expresses the fact you won't be able to ask for an older version than the "floor" one with a given baseline.

[dg0yt]

you won't be able to ask for an older version than the "floor" one with a given baseline.

Bu you can ask for it: overrides. It is just not considered by default.

[dg0yt]

It all starts with baseline and dependencies. That is a subset of a configuration which tested together in CI (subject to features, temporary issues etc.)

As part of dependencies, there is also version>=. This may select something above the "floor", but not below.

And then there is "ignore all previous instructions on versioning for this port". It is called overrides.

[heheda123123]

But after reading the official documentation of vcpkg, I still don't know how to obtain the baseline. For example, if I want to specify the use of zlib 1.2.11, how can I obtain this version's baseline?
https://learn.microsoft.com/en-us/vcpkg/consume/lock-package-versions?tabs=inspect-powershell

[autoantwort]

This is really a missing part in the ux.

I think currently the easiest workflow is to search for zlib in vcpkg.link, then click on versions. Select the version you want to use (1.2.11) and click on Subtree. You need the full commit hash that is now in the url: https://github.com/microsoft/vcpkg/tree/822eb4b4ce82d76fa5bcfa8f5774f47db4e01e8b/ports/zlib
=> The baseline is 822eb4b4ce82d76fa5bcfa8f5774f47db4e01e8b

[heheda123123]

Thank you, this does indeed solve my problem, but it is also a bit cumbersome. Specifying a version is a very basic feature in any other package manager, and I don't think it is necessary to have users search for a baseline themselves.

[Filoppi]

MS documentation states this:

A version baseline, establishes a minimum version floor for all the packages.
Baselines define a global version floor for what versions will be considered.

So it seems like the baseline simply blocks older versions from being used, but doesn't prevent new ones, meaning compatibility could still easily break if libraries changed?
It seems quite worrisome to me that you can't easily version lock all the libraries to the current version you are using without manually specifying the version of each library? Or am I missing something?

[autoantwort]

If you use a baseline all versions are set to the versions from the baseline. You can request "changes" against this baseline by using version>= or version overrides.