Packaging ROS for homebrew

[NikolausDemmel]

I'm opening this ticket to collect the thoughts and ideas that people have already had about this.

@wjwwood: Could you please copy your answer from [1] over here as a comment. I don't have enough karma to edit your post to get at the source.

I would say that generating formulae automatically with bloom is the only viable solution (as opposed to manually maintaining formulae). However, I actually started bottom up and experimented a little by manually creating some formulae (for now catkin, rospack, roslib) to see how the generated formulae should look like [2].

This has already revealed some issues. Most notably homebrew does at the moment not allow to specify a custom path where to install the formula contents. We would want to install e.g. in /usr/local/ros/hydro rather than /usr/local/ (or ideally /opt/ros/hydro, but homebrew has a strong promise to only touch /usr/local). Moreover, currently homebrew installs only stuff in the default FHS folders (bin, lib, etc, ...), but files/folders on the toplevel do not get installed (setup.bash, ...). Another issue is the question about python dependecies. On debian they all have apt-equivalents, but in brew world that is not done. However, there is the possibility for us to maintain such formulae for all the python module dependecies at least for the core packages. On the other hand, homebrew can at least depend on pip installed modules, such that their precense is checked. But it won't automatically call pip install for you. Maybe something in conjunction with rosdep can be done here. I would prefer sticking with pip for installing these.

Anyway, the install prefix issue has to be sorted out before automatic generation can be tackled. I asked the homebrew mailinglist, but didn't quite get enough info so far [3].

[1] http://answers.ros.org/question/130346/packaging-ros-with-homebrew/
[2] https://github.com/NikolausDemmel/homebrew-ros_experimental
[3] http://librelist.com/browser//homebrew/2014/3/9/installing-group-of-formulae-into-a-different-folder/

[mikepurvis]

"Most notably homebrew does at the moment not allow to specify a custom path where to install the formula contents."

A homebrew installation can be placed wherever. What about simply having one homebrew installation per rosdistro? Then everything is FHS-relative within /opt/ros/hydro, eg for ROS Hydro homebrew. Could be a relatively simple script to untar the homebrew install, connect up the Hydro tap, and then symlink /usr/local/bin/ros-hydro-brew to /opt/ros/hydro/bin/brew.

ros-hydro-brew install navigation

The alternative would be engaging the Homebrew maintainers to push the necessary changes upstream.

[wjwwood]

@mikepurvis I tried to setup a ROS only homebrew in /opt/ros before and ran into some troubles. It seems some software expects to be placed into /usr/local. It's not impossible, but it has its own bumps in the road.

Also you could just install one version of ROS at a time to /usr/local with no install prefix.

[wjwwood]

Copied over from http://answers.ros.org/question/130346/packaging-ros-with-homebrew/:

I have looked to do it for a long time now, but I have never had the time to setup everything. For now, all the time I can afford to spend on it is to keep it building from source on OS X.

From my perspective, the main challenges to getting this working are as follows:

• Generating Homebrew formulae for packages using bloom
• Setting up a CI system on OS X which has a clean starting point for each build
• Building bottles, pushing them to some storage (like download.ros.org/bottles), and updating the formula which uses the bottle

I think that generating Formulae for packages is the only sustainable way to approach this problem. There are nearly 800 packages in Hydro and 200+ in desktop-full. Packaging them by hand is error prone and unmaintainable. So coming up with a bloom generator for the formulae would be crucial. I started that work, but didn't get very far at all:

https://github.com/wjwwood/bloom_homebrew

The CI system for OS X has also been a challenge. I spent some time trying to setup a diskimage with COW for OS X which would behave like chroot/pbuilder for linux but ran into a lot of issues. The other thing I tried was using a VM and snapshots through a Python API, but that required Parallels which is not free and was slow. The Homebrew guys just clear /usr/local with git clean -fdx between builds for their "homebrew brewbot" system (https://www.kickstarter.com/projects/homebrew/brew-test-bot). I believe we (OSRF) are setting up a similar setup using jenkins on our build farms:

http://build.osrfoundation.org/view/SDFormat/job/sdformat-any-devel-homebrew-amd64/

If that is successful, I might try to use it for packaging ROS.

Finally, for bottle support (which would be awesome), we would need to also build each formula with the --build-bottle option, create the bottle, upload it somewhere (like download.ros.org/bottles) and then update the formula again, probably pushing the formula to https://github.com/ros/homebrew-hydro/.

So I have looked into it before, but as always progress on this is subject to my free time, which is in pretty low supply at the moment.

[NikolausDemmel]

@mikepurvis I think having additional brew installations is an interesting idea for a midterm makeshift solution, but not ideal. It would also mean that the user has to brew update/upgrade multiple times and complicates dependecy resolution (do we install all dependecies again for each distro (@wjwwood suggests that that might not even work without additional fixes in 3rd party software)? If not we don't have automatik resolution (rosdep could help) ).

Installing into /usr/local (only one distro at a time) also might be a good start, but we still have to find a solution for installing stuff that is not in FHS folders, like the setup.*sh files. Homebrew is quite hackable and the core devs very responsive, so I think we might be able to integrate a change that allows both custom install destination for ros formulae and linking of files ouside of FHS folders without too much effort. Let's see if this discussion [1] yields some more hints to a solution:

[1] http://librelist.com/browser//homebrew/2014/3/9/installing-group-of-formulae-into-a-different-folder/

[mikepurvis]

A possible advantage of a fully separate homebrew install is getting more control over the versions of dependencies, per REP3. The really big dependencies (eg, XQuartz, XCode tools) are installed outside of brew anyway, so it doesn't seem like it would be tons of duplication.

If I understand correctly, doing things this way would give the user choice to install in /opt/ros/hydro or /usr/local, at their option—whereas if the ros/hydro prefix is baked into the formulae, it's really just /usr/local/ros/hydro.

I'd be curious to know more about which formulae have path problems—among the ones we depend on, how many have issues? Is it possible we could push fixes to them, or are they intractable?

[NikolausDemmel]

I think versioned dependencies can be achieved also with one single homebrew installation, especially if we have a way to change the install path (which we could then also use for selected versioned dependecies, not only the ros formulae. The biggest potential conflict I see in REP3 is boost.). However, to fully support this will be challanging either way I assume. The main focus should be on support for the most recent distributions. It is an important point to keep in mind though.

The effective prefix would not necessarily need to be baked into the formula. I don't know how much is possible currently in homebrew, but if we need to extend it anyway, I imagine some form of grouping for custom install prefixes. So the formula says it wants custom install prefix "ros/hydro", which defaults to brew --prefix/ros/hydro, but can be globally configured by the user to any location he wants, including /opt/ros/hydro or /usr/local (I guess it is somewhat important to the homebrew people that per default, homebrew does not touch anything outside brew --prefix).

I would like to just be able to brew install ros-hydro-desktop and brew install ros-groovy-ros-base once ros/ros is tapped. Having to install a custom homebrew for each distribution with the implication of having to run update/upgrade n+1 number of times if I want to have n distributions installed makes me cringe a bit. It might be the more practical solution with less adjustments of homebrew (maybe not), but I'm not sure it's leading down the right path.

I'm not sure which formulae have path problems, but the wiki [1] indicates that it is probably not a matter of fixing just a bunch of formulae. It might be a different story if you only look at all dependecies of ROS (rather than all of homebrew), but no idea. Even if we don't do additional installations of homebrew, but rather custom install prefixes for just the ros formulae, this issue is still there if we want to provide some versioned dependecies. However, the versioned dependecies are even fewer than all the dependecies.

[1] https://github.com/Homebrew/homebrew/wiki/FAQ#wiki-why-does-homebrew-insist-i-install-to-usrlocal-with-such-vehemence

[mikepurvis]

Okay, sounds good. My apologies for derailing the discussion.

[NikolausDemmel]

No apologies needed. I value any alternatives and thoughts outside the box. Also, I'm no athority on which way this goes, just promoting my opinion ;-).

[NikolausDemmel]

@wjwwood : I have never used bloom myself. As I understand it there is quite some interplay between the bloom command line utility that a maintainer uses for releasing packages and that then triggering debians being built by some jenkins on a server. For the purpose of working on a formula generating backend, how much effort would there be to set up locally an environment where I can run my custom generator on a selected set of already released packages?

[wjwwood]

There are two ways to use bloom. First, you can simply use the generator to create the files needed for packaging a single catkin package on a specific platform. For example:

$ git clone https://github.com/ros/catkin.git
$ cd catkin
$ bloom-generate -h
usage: bloom-generate [-h] [rosrpm | rosdebian | rpm | debian] ...

Calls a generator on a local package, e.g. bloom-generate debian

optional arguments:
  -h, --help            show this help message and exit

generate commands:
  Call `bloom-generate [rosrpm | rosdebian | rpm | debian] -h` for help on a
  each generate command.

  [rosrpm | rosdebian | rpm | debian]

$ bloom-generate debian -h
usage: bloom-generate debian [-h]
                             [--place-template-files | --process-template-files]
                             [--os-name OS_NAME] [--os-version OS_VERSION]
                             [--ros-distro ROS_DISTRO] [-d] [--version]
                             [--unsafe]
                             [package_path]

Generates debian packaging files for a catkin package

positional arguments:
  package_path          path to or containing the package.xml of a package

optional arguments:
  -h, --help            show this help message and exit
  --place-template-files
                        places debian/* template files only
  --process-template-files
                        processes templates in debian/* only
  --os-name OS_NAME     OS name, e.g. ubuntu, debian
  --os-version OS_VERSION
                        OS version or codename, e.g. precise, wheezy
  --ros-distro ROS_DISTRO
                        ROS distro, e.g. groovy, hydro (used for rosdep)

global:
  -d, --debug           enable debug messages
  --version             prints the bloom version
  --unsafe              Makes bloom faster, but if there is an error then you
                        could run into trouble.

$ bloom-generate debian --os-name ubuntu --os-version precise --ros-distro hydro
==> Generating debs for ubuntu:precise for package(s) ['catkin']
No historical releaser history, using current maintainer name and email for each versioned changelog entry.
Package 'catkin' has dependencies:
Run Dependencies:
  rosdep key           => precise key
  cmake                => ['cmake']
  gtest                => ['libgtest-dev']
  python-argparse      => []
  python-catkin-pkg    => ['python-catkin-pkg']
  python-empy          => ['python-empy']
  python-nose          => ['python-nose']
Build and Build Tool Dependencies:
  rosdep key           => precise key
  gtest                => ['libgtest-dev']
  python-argparse      => []
  python-catkin-pkg    => ['python-catkin-pkg']
  python-empy          => ['python-empy']
  python-nose          => ['python-nose']
  cmake                => ['cmake']
==> Placing templates files in the 'debian' folder.
==> In place processing templates in 'debian' folder.
Expanding 'debian/changelog.em' -> 'debian/changelog'
Expanding 'debian/control.em' -> 'debian/control'
Expanding 'debian/rules.em' -> 'debian/rules'
$ ls debian/*
debian/changelog debian/compat    debian/control   debian/rules

debian/source:
format

I would start with a simple generator for Homebrew that can create a Homebrew formula for a single catkin package.

Once you have mastered that, you could move on the the next level of bloom which is to use a git repository to manage releases and generate one or more Homebrew formulae as part of the release process for ROS. For Debian, the released software goes through a few git branches, each giving the releaser an opportunity to patch the release, e.g. for ROS or for the OS or even for the particular OS version.

There is one level higher which is the release automation tool, which most people use. This tool automates the release process by cloning the release repo, doing a set of standard generations and branching commands, pushes the result and if the ROSDISTRO_INDEX_URL points to a repository that is on github.com it will open a pull request against it, to notify our build farm that new package (or new version of a package) has been released.

[NikolausDemmel]

@wjwwood : that was exactly what I was looking for. Thank you for the quick intro.

[NikolausDemmel]

I'm making progress on a basic generator. Quick question: Where is the logic that resolves dependecies like rospy to homebrew package ros/hydro/ros_comm?

Also: It's not quite clear to me how to get at the appropriate gbp repo / tar url from inside the bloom generator. I have to investigate what rosinstall generator does.

[wjwwood]

I'm making progress on a basic generator. Quick question: Where is the logic that resolves dependecies like rospy to homebrew package ros/hydro/ros_comm?

That is in rosdep: https://github.com/ros-infrastructure/rosdep/blob/master/src/rosdep2/gbpdistro_support.py#L108

Also: It's not quite clear to me how to get at the appropriate gbp repo / tar url from inside the bloom generator. I have to investigate what rosinstall generator does.

It uses the python-rosdistro library: https://github.com/ros-infrastructure/rosdistro

rosinstall_generator would be a good place to look.

[NikolausDemmel]

I'm making progress on a basic generator. Quick question: Where is the logic that resolves dependecies like rospy to homebrew package ros/hydro/ros_comm?

That is in rosdep: https://github.com/ros-infrastructure/rosdep/blob/master/src/rosdep2/gbpdistro_support.py#L108

Ah, it gets baked in the cache during update. That's why I didn't find it in the lookup code.

Also: It's not quite clear to me how to get at the appropriate gbp repo / tar url from inside the bloom generator. I have to investigate what rosinstall generator does.

It uses the python-rosdistro library: https://github.com/ros-infrastructure/rosdistro rosinstall_generator would be a good place to look.

Perfect. Actually, rosdistro might have enough info, such that the Formula can be generated for released packages without having a checkout with the package.xml. More on that later, once the basic proof of concept is working.

[NikolausDemmel]

What I don't understand yet why rosdep keys are mapped to a repo metapackage rather than to the individual ros package. Is the existance of this metapackage guaranteed and how is this enforced? Are those manually maintained? I'm talking only wet packages here.