Vcpkg: How to specify a version of a library

[Sleepyowl]

I cannot find any documentation on installing a specific version of a library.

Boost 1.65 breaks my build and I need to fall back to 1.64.

Is there a smart way to do that?

Currently I just git reset vcpkg to the commit right before boost version bump, but that's ugly.

[ras0219-msft]

Vcpkg's approach to accessing previous versions is exactly what you've done; either using git reset to freeze yourself to the set of library versions you need or using git checkout <sha> -- ports/boost to pull a specific version of a specific port forward.

You might also find the vcpkg export command useful if you only need the old set of libraries for a single project and you'd otherwise like to have the newer boost version available. Simply clone a second copy of Vcpkg (at the old commit), then install all the libraries you'd like to have, then use vcpkg export boost:x64-windows --nuget --zip to get a fully shrink-wrapped bundle of your projects dependencies.

This approach minimizes the burden on library authors and maintainers (how many boost versions must you test against? We say: only the latest supported upstream release), though the user experience can be rough as you've experienced and we do want to improve it in the future.

[mloskot]

This should make it into the docs

[rchiodo]

How do you decide when to switch? I'm having the same problem. Boost 1.65 breaks the boost unit test adapter so I have to go backwards.
It would be great if the command line could support different versions.

[eelstork]

If all you want is freezing packages at a given date, (I think that agreed upon ways to do relatively commonplace version-related things should be documented, either in the FAQ or someplace versioning is addressed):
git checkout (git rev-list -n 1 --before="2017-12-01" master)
(assuming Powershell)

Library authors are entitled to make breaking changes; so, I think that a practical approach to getting a specific version of a library should be provided. If I understand the current approach to "pulling a specific version of a specific port" this might involve manually inspecting port version changes in the control file? Reasonably, is that something we'd like to automate?

If so, would it be fine to avail an option for selecting a package version?

[Skylark13]

I would also like to be able to specify a version for a pacakge. It would make repeatable installs much simpler.

However, it might be hard to put in place, considering packages have dependencies, and currently everything seems to be built as DLLs. if two packages depend on a different version of a dependency (because the dependency had breaking changes between the versions), vcpkg would have to install and build both versions, and the DLLs would need to have different filenames so they can coexist in the same directory. Also, say my own project also wanted to use that dependency, I would need a way to specify which version's include path and lib to add to my project (not just the latest).

Still, it would be doable, and I think it would be a great addition.

[chris1248]

I can't believe this. Microsoft put all this time in making a package manager and you CAN'T specify the version you want? ARe you freaking kidding me? What good is any package manager if you _can't specify the version_?

[Knitschi]

What happens if you have a dependency tree that requires one package in multiple verisons?
I think to fully solve the dependency versioning problem the package manager needs some additional features:

1. Provide a way for packages to specify the version of the depended on packages.
2. Provide a way for a package at version X to specify a list of versions that are compatible to X.
3. Allow multiple versions of the same package to be installed at the same time.
4. Provide some sort of algorithm that tries to reduce the amount of parallel used package versions by examining the compatibility specifications. To make that work for let's say CMake projects, the find_package() function would also need to support the same compatibility specification.

[kejxu]

from another perspective, git reset also reverts everything outside the port path (source for vcpkg itself). In that way, patches or updates to older versions of packages have to target the older vcpkg API/interface. This limits those packages from consuming newer helper functions (if any) provided by vcpkg.

[ChrisEt]

Same problem here, also with the boost framework. Current version is 1.71.0 but the project I'm building requires 1.69.0.
Sure, I could simply go ahead and edit the 143 CONTROL files. Or I could git reset my clone to the version from 31st January 2019 (=1 year!) and hope that during this year no significant fixes or enhancements have been done to vcpkg!
Seriously, this can't be the solution, can it?

[cesss]

Really no PR for implementing this yet? I can understand that this feature was left at a side in the first vcpkg release, but it is so really necessary for complete the adoption of vcpkg in my projects, that I feel an imminent risk of modifying the source myself for my needs if I decide to adopt it.

And precisely, I prefer to avoid that, because I don't have the resources for maintaining a package manager at the moment, and moreover compatibility with older port files syntax should be preserved.

Nobody is working at implementing this? Really?

[ghost]

Same for me, how is this not on the roadmap by now?

I use vcpkg in multiple projects, and some of those projects require the same package, but at different versions. Now I have multiple vcpkg folders and need to keep track which folder is at which commit. Not really usable.

[JSoet]

Just adding another voice to this - just found out about vcpkg, thought that it sounded great, and was seriously considering using it, as we need to add some new libraries to our project and our existing method doesn't work that well.... but as I was reading through the documentation I was wondering how to specify a specific version and am surprised to see that that's not supported. Not being able to support specific versions basically makes this impossible for existing projects to adopt vcpkg, as often people can't afford to expend the effort to update all their libraries at once, and finding which specific commit supports the version that we need is not really viable.

[danperks]

Trying to make a Crow project but, being that it's no longer maintained, I need Boost pre-1.70. Seems like a simple enough feature to have.

[mukti5000]

Same here - vcpkg is great, and being able to specify package versions would make it even better!

[drearyworlds]

Adding my vote for this. NuGet has this feature. vcpkg should, too. Seems like updating the portfile to the latest version should not preclude one from leaving an a portfile pointing to the older version there.

[izosak]

Same here. I need to install an older version of OpenBLAS but can't do it using vcpkg!

[shogerr]

This is highly confusing for a user. You _must_ rollback the entire vcpkg repo? Man what a chore to even locate where in the commit history your update can be found. It's sometimes months before a new package version can be pulled int vcpkg anyhow. I guess the idea is to search the Github issues to locate when a change happened in libraries vcpkg tracks so you can locate the commit?

If there was even a reasonable way to hunt down package versions, this probably wouldn't be so off putting.

@Sleepyowl: You might try tinkering with something like what's below. Using Boost version 1.39.0.

cd c:\vcpkg
.\scripts\boost\generate-ports.ps1 -version 1.39.0

It will leave any packages that didn't exist at that version untouched.

PS M:\vcpkg> vcpkg search boost
boost                1.39.0           Peer-reviewed portable C++ source libraries
boost[mpi]                            Build with MPI support
boost-accumulators   1.39.0           Boost accumulators module
boost-algorithm      1.39.0           Boost algorithm module
boost-align          1.72.0           Boost align module
boost-any            1.39.0           Boost any module
boost-array          1.39.0           Boost array module
boost-asio           1.39.0           Boost asio module
boost-assert         1.72.0           Boost assert module
boost-assign         1.39.0           Boost assign module

[HoLue]

Nothing was done in the time since 2017 concerning this issue??? Such a "simple" feature request to install a specific version of a package... - or have I overseen something?

[mloskot]

@HoLue

Nothing was done in the time since 2017 concerning this issue???

https://devblogs.microsoft.com/cppblog/vcpkg-2020-04-update-and-product-roadmap/

[Ri0n]

Just took a look at the roadmap. I hope wrt versions they won't go Conan way which is very restrictive. For example you can't depend on openssl>=1.1 because openssl versions contain a letter after numbers and it breaks everything.

I prefer Gentoo Linux approach. They are way more tolerant to the all kinds of versions and allow to easily overwrite them.
https://dev.gentoo.org/~ulm/pms/head/pms.html

[bugproof]

@Ri0n what do you mean? https://conan.io/center/openssl/1.1.1g/?user=_&channel=_&revision=&os=&tab=overview is there any issue for that opened in conan repo?

[Ri0n]

is there any issue for that opened in conan repo?

IIRC yes. I also discussed this with Conan devs. And they said it's by design and instead OpenSSL developers should change their versioning to make version dependencies working. Currently Conan allows just exact version match for OpenSSL. For example a package may depend on openssl-1.1.1g but as soon as 1.1.1h is released a package maintainer has to change dependency in every package he uses or do some overwrite magic in its configuration files or just live with potentially insecure packages. There is no way to say "I want latest version from 1.1 branch".

I just hope vcpkg developers won't choose same way of versions handling.

[bugproof]

@Ri0n oh so you mean support for wildcards like 1.1.* or something like that which works for letters too or do you mean transitive dependencies and conan doesn't know which one to use if one package has 1.1.1g and other 1.1.1h because it doesn't understand letters.

[Ri0n]

@bugproof rather about version comparison (>, >=, <, <=) and yes, which works for letters too.

[mnesarco]

What? A Package dependency manager without package version support? Don't you think that it is absurd?

[nenomius]

Next step will be a package manager without support for packages.