golang style package management support

[zhangfuwen]

---

Is your feature request related to a problem? Please describe.

vcpkg for now, only allow user to install packages that have a port file in this repo. For some projects that are not so popular, ports may not be accepted.
Making a private port library/registry takes time and efforts.

Getting to know the correnct package name for a certain github projects takes effort.

Proposed solution

golang's package manager uses github/gitlab repo as a de-centralized registry. They use a full url(like github.com/username/packagename) of the repo as package name, which makes naming conflicts impossible. Packages are automatically supported by package manager as long as it is written following certain rules.

Can we take some of golang's idea and take packages(following certain rules) from github automatically?

This helps both package author and user.

We(vcpkg developer) don't have to maintain a larges port library.

If a package doesn't follow the rules, user can fork and apply patch himself and ultimately make a pull request to the original package author.

Given a github repo, user don't have to take any effort to figure out the correnct package name in vcpkg.

Describe alternatives you've considered

We can keep current port. An alternative would be that we make every fork of the packages and apply patches.

[JackBoosY]

Can you post an example so that we can discuss it better?

Thanks.

[zhangfuwen]

Can you post an example so that we can discuss it better?

Thanks.

hi @JackBoosY :

when golang user want to install a package, they type:

go get github.com/davyxu/cellnet

which is quite convenient and versitile.

for now, vcpkg allow us to:

vcpkg create handycpp https://github.com/zhangfuwen/handycpp/archive/refs/heads/main.zip "handycpp.zip"
vcpkg install handycpp

As a package consumer, I want to write a vcpkg.json in my project:

{
  "name": "gles-demo",
  "version-string": "0.1",
  "dependencies": [
    "github.com/zhangfuwen/handycpp",
    "pthreads",
    "happly"
  ]
}

and then vcpkg install.

vcpkg have enough facility to do this. A small script may easily achieve this goal using vcpkg. But I think we should take a step further and make it standard in vcpkg. This will encourage C/C++ authors to write standard cmake/vcpkg projects and eventually we will have a modern C++ package manager.

I think we should encourage package authors to do more in their project and write standard cmake or vcpkg project files. The ports currently in our repo are good. But it takes us too much effort to maintain.
Using golang's github oriented approach, even if package author is unwilling to write standard project file, package user may easily fork and contribute.

[JackBoosY]

I think this issue is more about describing vcpkg create.
In fact, I had a PR to improve the create command: #9430 but after some discussion, we think it's too complex.

The code in portfile.cmake contains the following parts:

1. Download and unzip the source code
2. Set options and link with the feature in vcpkg.json
3. configure, build and install
4. Repair the content after installation
5. Install the license.

We can do 1, 3 and 5, but 2 and 4 are not easy to solve:

For 2: The options for each port may contain complex dependencies and are compiler or system dependent. We need to look at its configuration file in detail before deciding what options to add.
For 4: Some of the generated configuration files may have path or content problems, we should add this part after testing.

[JackBoosY]

Note that different 3rd party libraries may use different configurators such as cmake, meson, qmake or others. Obviously, their usage is inconsistent.
And because of this, the configuration interface is not as unified as golang. This is also the reason for the current situation.

[zhangfuwen]

@JackBoosY I agree there is not a solution that will fix all problems. But I think even a solution that will work for some of the 3rd party libraries will make a point. Fow now, there is not even a rule for people to conform to. We should make the rule first and let library author conform to it later. Package managing with C/C++ is all a mess and I found vcpkg the most promising.

[JackBoosY]

@BillyONeal What do you think about this?

[BillyONeal]

I don't expect this to be something we are interested in doing soon, as

1. it makes transitive dependencies a potentially unbound set, which allows an unknowable amount of third party code to be run by customers without reasonable means for them to control
2. as proposed it fails the 'no changes means no changes' test, since there is no declaration of which version to build here
3. very few ports' portfile.cmake contents are automatically discoverable

Golang got to declare in advance a packaging format that their entire ecosystem agreed upon and most of their developers follow. There is no such standard packaging format for C++: that's why we have portfile.cmake in the first place.