ROS2 Build Tools & Systems

[peci1]

Rosdep (currently) does not allow git+ keys, or at least I haven’t seen it used anywhere. It can install packages using other strings than just package name, but it is unable to verify they are installed, and thus fails. Recently, I tried adding a rosdep pip rule to install pkg<2, but that doesn’t work. So I’d be really surprised if it worked with the git+ URLs. That is why I assume the Python package is in the workspace.

[Phil_Brown]

or.. ya know.. just make proper system packages?

Seeing as how ROS distributes standard packaged versions of ROS2 things for ubuntu 20, I would think it is quite reasonable, at least for the ROS required dependancies, to deliver them as actual system packages rather than using pip.

If downstream devs need to add even more things that would otherwise be pulled in by pip, then yes, other usage paths will need to be made available as well

I havent studied it too hard, but it sounds like perhaps pipx could be a way to go. And it is available on earlier platforms such as ubuntu 22, and I’m sure many others.

I would personally prefer ubuntu provided python3-xxx packages whenever possible, though.

[doganulus]

I assume I am not blacklisted and somehow managed to add a rosdep key into rosdistro/rosdep/python.yaml.

According to the the last answer here, this is the key format:

myCustomPkg:
    ubuntu:
        pip:
            packages: ["git+https://github.com/user/repo.git@master"]

[cst0]

@Phil_Brown

I would think it is quite reasonable, at least for the ROS required dependancies, to deliver them as actual system packages rather than using pip.

Wait, this is already what happens, right? I’m not aware of the base ROS install requiring or calling Pip for installation. In fact I think it’s pretty easy to break ROS things by pip-installing python packages originally installed via apt.

But to be honest I have to recognize that I’m not super familiar with all the underlying mechanisms at the moment, which is why I’ve mostly bowed out of the conversation here.

[mjcarroll]

@Phil_Brown

or… ya know… just make proper system packages?

Seeing as how ROS distributes standard packaged versions of ROS2 things for ubuntu 20, I would think it is quite reasonable, at least for the ROS required dependancies, to deliver them as actual system packages rather than using pip.

We do! This is why in the installation instructions for ROS 2 either from binary or source you won’t find the use of pip, only apt to manage dependencies.

[mjcarroll]

@doganulus

That’s right. But rosdep does not solve this case: The happy ROS user develops a C++ ROS package and declares a dependency on my Python package via a rosdep key pointing to git+.... Rosdep runs pip. Pip does not know about my package.xml. You somewhat assume my package is their workspace but this is the task for rosdep if it is the tool you claim.

When you define a rosdep key, you are effectively handing off dependency resolution to the package manager. In that context, it makes sense that pip would not be aware of the package.xml, any more than pip correctly handling Cargo.toml files.

For Ubuntu-based systems, this means that apt will figure out which other packages are required to install to support the package you requested. For example, a dependency on opencv may also bring in ffmpeg, blas, lapack, or whatever is specified as necessary by the apt package. We have similar functionalities for other distribution package managers like rpm, brew, etc.

Similarly, for pip, the package would have to correctly specify it’s dependencies that need to be installed for that package to function. We have similar functionalities for other language managers like Ruby’s gem system.

–

rosdep specifically solves the case with two conditions:

1. You have a rosdep key that is package that is ROS-based and has already been released into the ecosystem (that it, it appears in a distribution.yaml file for your distro of choice)
2. You have a system dependency that is not ROS-based and is apt or pip installable.

–

I’m not sure why in your case the user couldn’t create a venv, pip install the repository, and then use that dependency freely as part of another C++ package. I suppose pip wouldn’t be able to install apt packages, so you would have to assume a working ROS install.

The way around that would be to have a pip install ros, so you could install all of ROS2 inside a virtual environment, but I have no idea how to even approach doing that.

[Phil_Brown]

oh, very nice!

in that case.. how about providing an easy-to-use way for end-users of ros to similarly package up their own ros related code?
(which would ideally include things they have to pull via pip to support their own code)

Is there one already?
I have been presuming not, since most ROS folks I know are doing direct pip pulls.
Any time I try to search on “ROS” plus"package", I only end up with results for ROS’s odd notion of “package”.

(whereas my idea of a package, is something that generates a single file, that I can then archive, and extract on a production machine)

This might tie in with the future use of venv.
If there is a standard expected location for venv files, then perhaps there is room for some kind of
command, such as

rosmake os-package (or “os-distro”, or whatever you like)

Although perhaps it would make the most sense to have a separate build target JUST for the venv, since likely a developer could have multiple ros packages to build, but they would share a common venv.

rosmake os-package-venv

?

[cst0]

Is there one already?

Yes, this is what the buildfarm automates. The ROS package format contains all the information a .deb package needs to be built and distributed, and you can do it locally if you’d like to. The buildfarm handles distributing the resulting .deb so it can be installed via apt-get install, but you can also just run it locally, get a mypackage.deb, and then run apt to install that local file.

The tool is bloom and it’s described in more detail in the documentation.

[mjcarroll]

@Phil_Brown

in that case… how about providing an easy-to-use way for end-users of ros to similarly package up their own ros related code?

This is precisely what the ROS buildfarm does. It turns repositories with ROS code in them into binary debian or rpm packages. You “release” your package and open a pull request against rosdistro, which tells the buildfarm that you are ready to release your package and have it built. There is a full guide here: Releasing a Package — ROS 2 Documentation: Iron documentation

Edit: @cst0 beat me to it, again