[FEATURE REQUEST] VCPKG support?
Please confirm these before moving forward
- [X] I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
- [X] This proposal is a completely new feature. If you want to suggest an improvement or an enhancement, please use this template
Describe the new feature
There is support for pip, npm. It would be cool to have vcpkg support :)
Describe how this new feature could help users.
vcpkg is one of the most popular package managers for C++
I decided to start working on this, and I was thinking about how to manage different triplets, because you might want libraries in different triplets (for example, for cross-compilation or using MinGW separately from MSVC). My plan was to have each triplet be its own source (like how WinGet has different sources), with the "vcpkg built-in triplets" being the sources given by default but with the ability to add custom, "VCPKG community triplets". I'd like to get feedback, though; does that sound like a good idea / like it fits with the existing codebase?
It looks good so far, The only concern I can think of is if vcpkg installs packages per-directory, instead of per-user or per-machine. I have no idea of how vcpkg works, so provided that it has some per-user or per-machine behaviour, it should fit in
I have a question about how to implement package searching - since most packages can be compiled for any triplet (source), right now I have it so that it simply gets a list of applicable packages and then provides them for EVERY TRIPLET installed on the system. However, this results in a flood of duplicate packages from different sources.
I was thinking one solution to this would be to have all the sources disabled by default on the left in the search packages dialog, although I'm not sure if that's possible to implement. Another option is only listing packages for the default / host triplet, but for cross-compilation (and even a mix between MSVC and GCC compilation on the same machine) that seems to be an inadequate solution.
Is there a way to automatically disable the vcpkg source, or maybe do you have a better idea? I'm not sure if I should be mucking with that code...
Do you think it would make sense to have a default source? Or have the user select the triplet they want to install at runtime?
I mentioned a default source in the response; my system has a VCPKG_DEFAULT_TRIPLET environment variable to tell vcpkg which source to use by default, and there's already a logic check in place for a default source if that's not the case. The issue I have with that is that for people (like me; I've done this before) that are compiling with MSVC and GCC (or a few other scenarios in which two triplets would be active); those two compilers need a different triplet each to work, and so I feel this should support multiple triplets as you can have multiple triplets in use on a single system for a variety of reasons. I suppose if you need to install something for a different triplet from the default you could just do it from the command-line?
User selection was the other thing I was thinking, however I'm not sure how I would accomplish that. I was thinking maybe a dialog box, but not only am I not accomplished enough in XAML and C# to add that, I wasn't sure where to add the dialog calling code either.
Sorry, I didn't see your reply until after I created the pull request! If you want me to fix the discovery code, you can reject the pull request until I've updated the code.
User selection was the other thing I was thinking, however I'm not sure how I would accomplish that. I was thinking maybe a dialog box, but not only am I not accomplished enough in XAML and C# to add that, I wasn't sure where to add the dialog calling code either.
I can handle this, don't worry about the UI integration.
Perhaps it would be useful (looking into adding more package managers in the future) to add some kind of generic API to request the user for a choice/data input just before an installation operation begins, what do you think? Could this solve more adequately this issue while providing a non-vcpkg-unique solution?
I think that's a great idea. Maybe asking the manager what sources a package can be found in, and then asking the user what source to install the package from? I don't think it's that uncommon for different package manager sources to have the same package, and that would definitely fix the vcpkg problem while being applicable to all package managers. Or possibly just a more agnostic text input choice, which would still fix the issue for vcpkg specifically and would be more extendable, if less fool-proof, for other managers.
I propose, as an action plan:
- We now use a default source. A fast and good enough solution to publish the package manager as
[EXPERIMENTAL]on new UniGetUI releases, and get user feedback. You can easily implement it by usingSettings.GetValue(setting_name), and I will take care of adding an entry on the settings UI. - I am planning on improvements on how operations in general work (for UI detachment), so it will be a great time for me to implement those generic questions/dialogs called from pacmans. However, I can't give an ETA on this, so on this second phase i'd let you know about it, so we can get this properly fixed
Sounds good! I tried to add the setting UI, but while the combo box shows up the setting isn't saved. I'm going to leave it in the pull request, though, because to setup the values of the combo box some helper functions are needed. There should be a TODO on line 184 of SettingsPage.xaml.cs above the combo box detailing what it should be comprised of. Other than that, I'm fairly sure it will work; the setting is in use, as well as the defaults if the setting is not provided; it just needs to have the DefaultVcpkgTriplet setting set properly. I'm going to commit it and resubmit the pull request for you to review; please let me know if there's anything you want me to fix.
Let me know about the second phase when you get around to it!
Thanks!
Expect a week or two before I add the setting and merge the PR