Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC: Package vcpkg-generated binaries as Chocolatey packages? #2
Looking into ROS2 effort to package dependency in Windows  I noticed that they distribute some of their binary dependencies  as
I wonder if we could modify the scripts in this repo to package the compiled version of
This approach would drastically simplify packaging of libraries with a lot of dependecies such as PCL , but could present the following challenges/things that need to be properly understood:
 : https://github.com/ros2/ros2/wiki/Windows-Install-Binary
We've definitely considered this approach and deemed it a bit too complex and out-of-scope for now -- if you can make it happen cleanly that would be incredible
Let me lay out some of our reasoning that you might find provocative or useful; apologies in advance for the wall of text!
The conclusion that Vcpkg comes to (regarding all this) is, essentially,
Though it may be obvious, ROS in the "Vcpkg model" would look like:
 Defining "effective ABI version" such that "all consumers of X will be satisfied with any binary package that has the same effective ABI version"
Thanks @ras0219-msft for the great insight behind
Just to clarify, my idea on how to use the installer generated by this repo (using the Qt Installer Framework, either online or offline) is quite similar to the "Vcpkg model" that you explained:
The last possibility of having an "update" that is breaking the ABI may seem risky, but typically in systems targeted to developers (such as homebrew), users know that any update in the software will require a complete rebuild of their software. Clearly this system would need to be used only for development, and never for actual deployment in production.
Slightly related: I recently found this discussions on the Homebrew issue tracker on how the deal with versions/ABI compatibility, they are definitely an interesting read: Homebrew/brew#60 , Homebrew/brew#620 , Homebrew/brew#1937 .
The Chocolatey packages that you've found in your links  and  are exploratory and don't necessarily represent the way we plan to package ROS 2 overall. We currently use Chocolatey to install dependencies on our Windows CI build machines so it was natural to try and use it to package additional dependencies as a trial to see how doable generating Chocolatey packages would be.
All I mean by the above is that we aren't committed to using Chocolatey, but we have a community that defies the standard "flavors" of package management strategies. Yes we're installing developer libraries and tools, which Chocolatey doesn't necessarily want to handle but we want to provide those as pre-built binaries for a known set of target systems and we already have tooling for comprehensive source builds which works across platforms and is not . Migrating to or replicating all that work with vcpkg doesn't appear to get us any closer to binary packages for Windows which is my chief concern. vcpkg looks like a great tool, but it's looking likely that it's not the right one for ROS 2's needs.
Thanks @nuclearsandwich for weighing in the discussion!
Good to know, we set up this repo exactly for explore how to package a distribute a big group of Windows library binaries with a lot of interdependences, and until we were going toward the idea of packaging them using the Qt Installer Framework and its online capabilities (http://doc.qt.io/qtinstallerframework/ifw-overview.html). Chocolatey was an interesting alternative for which I was curious to hear opinions.
I am not sure I am getting your point. I know the extensive work done by the ROS community/OSRF on built tools (in the sense defined by ros2/design#115), but as far as I understand all this effort have typically been used to build a huge group of packages with similar build systems (again, in the sense of ros2/design#115), i.e. the one that then are typically packaged using
The type of software of which I was thinking are instead the "system dependencies" that are typically installed in Linux using the system package manager or in macOS using Homebrew.
As far as I know, even on ROS, most of these libraries are typically obtained from the system package manager (via
referenced this issue
Feb 13, 2018
referenced this issue
Mar 4, 2018
Related to this old discussion, today Microsoft announced the project of porting ROS1 on Windows, https://blogs.windows.com/windowsexperience/2018/09/28/bringing-the-power-of-windows-10-to-the-robot-operating-system/ .
I briefly checked the project, and apparently the ros-win developers (I guess @seanyen-msft and @johnsonshih ) had the same problem discussed in this issue, but they choose to deploy their library (mostly C/C++) binary dependencies as Chocolatey packages, see https://ros-win.visualstudio.com/ros-win/_git/rosdep-au-packages . Those packages seems to just contain the