Alternative resolutions for the same key

[NikolausDemmel]

Here is a proposal for how to realize this:
http://xylem.readthedocs.org/en/latest/design.html#alternative-resolutions

A extensive proposal for the configuration of installer priorities completely without number-valued priorities, but still considering the three sources of information (os plugins, installer plugins, user config).

Feel free to comment / discuss in this issue.

[NikolausDemmel]

cc @wjwwood @tfoote @dirk-thomas @esteve

[wjwwood]

I think that all makes sense. The concepts and rationals are all very well laid out, but I do fear we are taking on a lot of complexity in exchange for this flexibility. Hopefully that is offset by the high quality documentation we have describing it, but either way we should remain mindful of the complexity level.

+1 from me on this topic.

[NikolausDemmel]

I do agree that this (together with the other proposals) introduces considerable complexity to the rules files and config options compared to rosdep. However, it should remain true that for the large majority of users the defaults are fine, i.e. they do not need to even create a config file.

Creating a general purpose tool where ROS specifics are merely instantiations of more general concepts will always increase complexity. The tricky part is hiding the complexity from (most of) the users.

[NikolausDemmel]

Here the link was also stale. I now fixed the link, which points to a considerably more elaborate discussion which considers 5 use cases.

[wjwwood]

I think the one I was looking at had the 5 use cases before, either way I didn't see anything new.

[tfoote]

Generally it looks reasonable. The one element that I don't like is the "disable" keyword. All other rules are simply declarations and it's up to the configuration to choose which declaration to use. If you want to provide an updated rule for something that is fine. By allowing a rules file to disable another rule, the rules files become part of the configuration and cannot be overridden by the users config. Adding foo via pip has no bearing on whether foo is was or will be available via apt and we should leave that up to the user to choose in their config.

[NikolausDemmel]

@wjwwood: I'm not actually sure what happened. When I orginially posted the issues (and presumably when you looked at them) the links to the plugin branch included the most recent version. When Tully looked at it, it a couple of days later, it was somehow reverted to a previous version. Might have to do with the merge. Anyway I have in the meanwhile updated all links to master.

@tfoote: So the reason I suggest a way to overwrite an existing installer rule in a higher-priority rules file is that without it, there is an assymetry in the what I can overwrite in a higher-priority rules file. Consider this:

# 01-custom-rules.yaml
foo:
  ubuntu:
    any_version:
      apt: [custom-foo]
# 20-default-rules.yaml
foo:
  ubuntu:
    any_version:
      apt: [libfoo]

versus

# 01-custom-rules.yaml
foo:
  ubuntu:
    any_version:
      pip: [custom-foo]
# 20-default-rules.yaml
foo:
  ubuntu:
    any_version:
      apt: [libfoo]

In the first example, a user that wants to customize the resolution of foo to resolve to another apt package can do so in a custom/local rules file. In the second example if he wants to do the same thing but for another installer, he also needs to put a install_from: pip: [foo] in a config at the same time (and possibly create that config file in the first place). Now this is not the most terrible thing for a rare use case, but conceptually it is unsatisfactory to me.

Another example is your friendly neighborhood robot vendor, that provides you with a custom rules on top of the default rules to support their new "bar robot". You install their bar-robot-python package, which among other things installes the addition sources file as a xylem plugin.

Imagine 01-custom-rules.yaml to be 10-bar-robot-rules.yaml in the above example. It happens to be the case for "bar robot" to function properly, it needs foo installed from pip. Without a way to overwrite the existing apt rule, in order for xylem to work properly with "bar robot", the install instructions need to include a step that says "manually add install_from: pip: [foo] to your xylem config file". Suboptimal IMO.

But this is a minor feature and we don't have to keep discussing it and just leave it out for now.

[tfoote]

I think the robot distributor case you defined can be resolved using version dependencies rather than knocking out the installer rules. As it should be that you are not tied to the installer method but a newer version of the package.

[NikolausDemmel]

What kind of versioning are your referring to? Do you mean the robot vendor introducing a new xylem-key like foo-1.2 that refers to a specific version of that library that he needs?

[tfoote]

This would require package version dependencies, either in different keys or by us adding version dependencies (we've discussed it but think we're leaning away from supporting it)