Missing install files for Ubuntu Noble?

[ruffsl]

Looks like the hooks for colcon-argcomplete are missing with the debians that ship for Ubuntu Noble.

• https://colcon.readthedocs.io/en/released/user/installation.html#enable-completion

Expected:

docker run -it --rm ros:iron bash
apt update && apt install -y \
   python3-colcon-argcomplete
find / -name colcon-argcomplete.bash
ls /usr/share/colcon_argcomplete/hook

/usr/share/colcon_argcomplete/hook/colcon-argcomplete.bash
colcon-argcomplete.bash  colcon-argcomplete.zsh

Result

docker run -it --rm ros:jazzy bash
apt update && apt install -y \
   python3-colcon-argcomplete
find / -name colcon-argcomplete.bash
ls /usr/share/colcon_argcomplete/hook

ls: cannot access '/usr/share/colcon_argcomplete/hook': No such file or directory

@cottsay @nuclearsandwich

[ruffsl]

Oddly enough, it looks like function for colcon-cd are still in the right place for jazzy:

$ ls /usr/share/colcon_cd/function
colcon_cd-argcomplete.bash  colcon_cd-argcomplete.zsh  colcon_cd.sh

[tonynajjar]

I independently confirm this observation

[adivardi]

I also have this issue. Any idea on what's the cause and possible fixes?

[AngeLoGa]

This is still an issue right? Is there any way of installing colcon-argcomplete in Ubuntu Noble?

[cottsay]

Debian/Ubuntu have decided to package colcon in their repositories. For better or worse, they made different decisions regarding where to place files on disk. Unfortunately, their deb packages sometimes take precedence over the deb packages we've produced on Package Cloud and distributed in the ROS repositories.

This is an artifact of those decisions. The installation and usage instructions reflect the packages we produced and have distributed, and unfortunately the "upstream" Debian/Ubuntu packages work differently.

$ apt list python3-colcon-argcomplete -a
Listing... Done
python3-colcon-argcomplete/noble,now 0.3.3+ds-2 all [installed,automatic]
python3-colcon-argcomplete/noble,noble 0.3.3-1 all

The first one is part of Ubuntu Noble, the second one has been in the colcon Package Cloud and ROS repositories for a long time. If you "downgrade" to our package, the file will appear as it always has in previous Ubuntu releases.

[AngeLoGa]

I see, my apologies, I failed searching the package correctly and that is why I thought it wasn't installed when in reality it was due to versions. Downgraded and indeed colcon_cd is where expected.

[ruffsl]

If you "downgrade" to our package, the file will appear as it always has in previous Ubuntu releases.

@cottsay , Isn't there an apt config to prioritize apt installing from various repositories?

• https://manpages.ubuntu.com/manpages/focal/en/man5/apt_preferences.5.html

Should we update the ROS install instructions to bolster the default preference prototype for ROS's apt source list?

[LastStarDust]

I just found out about this issue and realized that my problem has already been discussed here.
colcon/colcon.readthedocs.org#103

[cottsay]

Quick update here.

I tried taking the same approach as ROS infrastructure packages to make our deb packages take precedence over the system ones by bumping the incremental version to be ridiculously high (-100). It appears that the ONLY package this didn't work for was colcon-argcomplete, because the debian/ubuntu package has a version suffix (+ds) which appears to give it precedence. How frustrating.

We're iterating on a new solution.

It is possible to use apt repository pinning to control this, but it isn't something we want users to have to configure to install packages correctly.

[ruffsl]

install instructions to bolster the default preference for ROS's apt source list?

Earlier, I attempted to refactor my local apt source list files to prioritize ROS apt repo, by simply moving entries around:

you must put them in top of "sources.list" if you want to assign highest priority

• https://askubuntu.com/a/153408

But didn't seem to work, as per the version suffix related reason you just described:

It appears that the ONLY package this didn't work for was colcon-argcomplete, because the debian/ubuntu package has a version suffix (+ds) which appears to give it precedence. How frustrating.

I just noticed that when comparing what I had installed locally with that from package.ros.org:

• http://packages.ros.org/ros2/ubuntu/dists/noble/main/binary-amd64/Packages

We're iterating on a new solution.

Happy to beta test when ready!

[cottsay]

Happy to beta test when ready!

I pushed a new version to the packagecloud repo. Give that a shot if you have a chance.