vcpkg export issues

[yamcenutzer]

OK, at least a start, but:

1. the exported file/nuget package should be allowed to have a decent name, not just the date-time
2. people who need to use nuget for native typically maintain their own collection (e.g. artifactory), so
   packets need to be created individually, and if they have dependencies, then they need to be linked to.
   Example if I create a boost package now, I get zlib and bzip2 in it. I have no idea which version of these are used.
   If I now additionally create a protobuf package, I again get zlib , etc...
3. versioning is still missing
4. why, are all headers replicated for each target triplet, is that really necessary?

[alexkaratarakis]

the exported file/nuget package should be allowed to have a decent name, not just the date-time

Yes, indeed! We are working on a --output="name" option but we wanted to enable vcpkg export as soon as possible to get feedback like this.

I have no idea which version of these are used.

We plan to include a text file in each exported package with a list of included libraries and their version.

if I create a boost package now, I get zlib and bzip2 in it. ... If I now additionally create a protobuf package, I again get zlib , etc...

Vcpkg provides a guarantee that all libraries are built against each other, eliminating the possibility of mismatching versions. The simplest and most robust way to express this in NuGet is to package them all together (including all dependencies). We are aware that this has some downsides.

For the example you mentioned, using vcpkg export boost protobuf --nuget results in a package that contains both of them and there will be a single copy of zlib with the guarantee that both protobuf and boost are built against that single copy of zlib. In the case of zlib, this would probably work (it's very stable), however if the conflicting library is boost then there is no safe way to resolve the conflict because boost's ABI breaks between each version. We solve this for the general case by always packaging the entire consistent set together.

versioning is still missing

Vcpkg is designed around the premise that you want exactly one version of each library to be loaded in a single process. If you are building two different applications (processes) that require different versions of libraries -- which is definitely supported! -- then we recommend using two different vcpkg enlistments, one for each application. See our FAQ [1] for more on this.

why, are all headers replicated for each target triplet, is that really necessary?

We believe having a separate folder for each triplet is the most reliable and robust experience. We have looked into unifying the include\ folder but it gets really complicated in practice especially when taking into account that libraries can modify their headers as part of their build.

[1] https://github.com/Microsoft/vcpkg/blob/22848e4b7e29a3a74c28afafe4d177e541ec8638/docs/FAQ.md#how-do-i-use-different-versions-of-a-library-on-one-machine

[jozefizso]

I love the idea of exporting built packages to nuget. These two are showstoppers:

1. nuget package name cannot be changed
2. nuget package version cannot be changed

It would be great to have ability to specify our own .nuspec template, because when we put vcpkg generated nugets to NuGet Gallery, they does not provide any identifiable information.

This is a nice to have feature with nuget packages:

• each port is packages into its own nuget and have matching version numbers

[zabulus]

Maybe it's worth mention.
There is project CoApp that allows to place built libraries and include headers to nuget package and provides convenient way to integrate packages to projects. It has many different pivot points for configuration in which library could be built similar to triplets.
Currently project is somewhat abandoned, but still functional. Plenty of nuget packages built using it are placed on nuget.

[yamcenutzer]

that was dead years ago. Is it alive again?

[zabulus]

@yamcenutzer no further development AFAIK, but already released stuff still works and integrates with recent product versions (VS, nuget).
I mentioned it because I think some design decisions from there could be borrowed and/or reused for the export feature of vcpkg

[ras0219-msft]

@zabulus CoApp was a good experiment to see what C++ would look like if it was packaged directly into NuGet like C# is. We actually _have_ reused a lot of the techniques that CoApp originally pioneered for our NuGet export!

However, CoApp has some drawbacks when applied to open source software, many of which stem from a binaries-first mindset. I've had the great fortune to chat with @fearthecowboy (author of CoApp) on several occasions and I'd like to think we've tapped some of his experiences in the design of Vcpkg :).

[jozefizso]

The CoApp is not maintained anymore.

vcpkg makes much more usable NuGet packages. It just needs to improve how packages are named and versioned, so we have more descriptive packages referenced in our source code and stored in our NuGet Gallery.

[ras0219-msft]

@jozefizso You're absolutely right that we need to add the ability to substitute the nuspec information.

While it isn't anywhere near as convenient as supplying it up-front (not to mention unscriptable), I've had great success using the NuGet Package Explorer[1] to modify the metadata from pre-created NuGet packages, which should hopefully work for the "upload to the NuGet Gallery" case.

[1] https://github.com/NuGetPackageExplorer/NuGetPackageExplorer

[jozefizso]

Yes, we can manually update .nuspec file, but it's less convenient then having

vcpkg export --nuget --pkgname protobuf --pkgversion 3.1.0

And this would work much nicely with build scripts :)

[ras0219-msft]

Thanks everyone for your suggestions! I've just pushed 06597edfb which adds --nuget-id=... and --nuget-version=....

Example:

vcpkg export --nuget --nuget-id=cpprestsdk.x86.deps --nuget-version=2.9.1 boost websocketpp openssl

[scramsby]

For the company CI scenario, having NuGet export support exporting multiple packages (one per dependency) instead of a single mega-package would be useful. As I've seen mentioned elsewhere, if the vcpkg system understood the dependency graph, it could create inter-package dependencies in what it generated with exact version matching. That way you'd still get the guarantees of ABI compatibility but allow clients to be more specific in what each of their consuming projects depend upon. This would have the added benefit that the consuming projects wouldn't need to copy down multiple largely redundant NuGet packages (if you created separate mega packages per target application) where there is significant overlap between multiple applications' dependencies that are being built on the same machines.

[uecasm]

I second what scramsby said. Although having said that, unless I'm missing something it looks like the way that VcpkgRoot is defined will prevent anyone ever using more than one vcpkg nuget file in a single project anyway -- which seems like a serious bug.