catkin profile commands fail with non-existent extend directory

[jonfink]

System Info

• Operating System: Darwin desiderius 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64
• Python Version: Python 2.7.10
• Version of catkin_tools: catkin_tools 0.4.2
• ROS Distro: jade

Expected Behavior

In a workspace where several catkin profiles have been defined to work with different ROS distributions (i.e., a jade profile extends /opt/ros/jade while a kinetic profile extends /opt/ros/kinetic) but some of those distributions are not installed, one should still be able to freely list and set available catkin profiles.

For example (on a system with /opt/ros/jade but not '/opt/ros/kinetic'):

$ catkin profile list
[profile] Available profiles:
- default (active)
- jade
- kinetic

$ catkin profile set kinetic
[profile] Activated catkin metadata profile: kinetic
[profile] Available profiles:
- default 
- jade
- kinetic (active)

$ catkin profile set jade
[profile] Activated catkin metadata profile: kinetic
[profile] Available profiles:
- default 
- jade (active)
- kinetic

Actual Behavior

Again, on a system with /opt/ros/jade but not '/opt/ros/kinetic':

$ catkin profile list
[profile] Available profiles:
- default (active)
- jade
- kinetic

Note, default profile extends nothing

$ catkin profile set kinetic
[profile] Activated catkin metadata profile: kinetic
[profile] Available profiles:
- default 
- jade
- kinetic (active)

$ catkin profile set jade
Traceback (most recent call last):
  File "/usr/local/bin/catkin", line 9, in <module>
    load_entry_point('catkin-tools==0.4.2', 'console_scripts', 'catkin')()
  File "/Library/Python/2.7/site-packages/catkin_tools/commands/catkin.py", line 258, in main
    catkin_main(sysargs)
  File "/Library/Python/2.7/site-packages/catkin_tools/commands/catkin.py", line 253, in catkin_main
    sys.exit(args.main(args) or 0)
  File "/Library/Python/2.7/site-packages/catkin_tools/verbs/catkin_profile/cli.py", line 106, in main
    ctx = Context.load(opts.workspace)
  File "/Library/Python/2.7/site-packages/catkin_tools/context.py", line 171, in load
    ctx = Context(**context_args)
  File "/Library/Python/2.7/site-packages/catkin_tools/context.py", line 270, in __init__
    self.extend_path = extend_path if extend_path else None
  File "/Library/Python/2.7/site-packages/catkin_tools/context.py", line 547, in extend_path
    raise ValueError("Resultspace path '{0}' does not exist.".format(value))

Steps to Reproduce the Issue

(On a system that has /opt/ros/jade but not /opt/ros/kinetic)

mkdir test && cd test && catkin init
mkdir -p .catkin_tools/profiles/jade
echo "extend_path: /opt/ros/jade" > .catkin_tools/profiles/jade/config.yaml
mkdir -p .catkin_tools/profiles/kinetic
echo "extend_path: /opt/ros/kinetic" > .catkin_tools/profiles/kinetic/config.yaml

Note: I am manually creating the profiles here since catkin will prevent me from creating the kinetic profile. However, in our use-case, these profiles are checked out of a repository, so this "check" won't really catch things.

Behavior described above will now happen (one can set the kinetic profile but then not change it).

[mauriceAlthoff]

is someone working on this issue?

[wjwwood]

@mauriceAlthoff I don't think so. I personally do not have time to spend on it at the moment.

[TwoRedCells]

I encountered what I think is the same issue. The trick is to manually delete the hidden catkin dir.

$ cd happy_ws
$ sudo rm -R devel/
$ sudo rm -R build/
$ sudo rm -R .catkin_tools/
$ source /path/to/setup.bash
$ catkin init

[AlexisTM]

@jonfink I have the same issue. I have a system-wide melodic profile and a docker running kinetic.

If I worked on the docker over kinetic profile, I can switch to melodic profile but not back to 'kinetic because the extend directory (melodic`) doesn't exist on the docker.

Also, I cannot switch to melodic from kinetic from the system.

I would agree on the opposite: Fails to switch to a new configuration that doesn't have a proper extend folder.

[AlexisTM]

@jonfink I found a quickfix, see: #566

[mikepurvis]

Closing via #566.