pyquaternion: 0.9.6-3 in 'kinetic/distribution.yaml' [bloom]

[Achllle]

Increasing version of package(s) in repository pyquaternion to 0.9.6-3:

• upstream repository: https://github.com/Achllle/pyquaternion
• release repository: https://github.com/Achllle/pyquaternion-release.git
• distro file: kinetic/distribution.yaml
• bloom version: 0.9.1
• previous version for package: null

pyquaternion

Post ROS package conversion
* Change exec depend naming from numpy to python-numpy
* Add numpy dependency to package.xml
* Create catkin package, rename and move some files
* Fix casting error in trace_method
* Add setter for vector

[Achllle]

This package is a requirement for the dual-quaternions and dual-quaternions-ros packages, see also #23261

[clalancette]

So how does this relate to the pip key we have called python-pyquaternion-pip?

[Achllle]

Same package.
My reasoning was based on @tfoote 's comment on #23261 that pip was not the right way to release and follow-up comment that everything has to be in apt. I also don't like the default behavior of rosdep that it runs pip install as root, which doesn't play well with virtualenv. Finally, I am considering releasing a cpp version, along with the cpp version of dual_quaternions, although this is not a near-term thing.
If the pip package is preferred or if there only can be one, happy to withdraw the PR.

[tfoote]

If we're going to package it here, we should just pull the pip version so that we don't get conflicts. Can you update this PR to remove the pip rosdep entry?

[Achllle]

done. I do want to note for full transparency that along with the additions to turn the package into a ROS package, I made some minor changes that are not yet in the original package.

[tfoote]

That should be fine. Just be careful doing that with too much. We've done that in the past and been bitten when the upstream didn't take the change and then we were stuck maintaining it in our fork. If it's mostly packaging changes those are more common, the API changes are the most at risk of being a maintenance burden.

[Achllle]

Reverted one change and opened a PR into the original repo for another fix

[PymZoR]

This is a breaking change in rosdep as the key as been changed. That broke our CI, how can we avoid this in the future ?

[clalancette]

This is a breaking change in rosdep as the key as been changed. That broke our CI, how can we avoid this in the future ?

Arg, sorry about that. I'm actually going to revert this for now, as I don't really know the way forward here.

FYI @tfoote @Achllle

[tfoote]

With this change it is expected that the pip key stops resolving. The solution is to switch to the ROS package that was provided in it's place that will now be available as a ROS package. And this will allow other ROS packages to be released.

All global pip rules like this are going to cause potential regressions when we replace them with the preferred native packages or in this case ROS packages. Unfortunately we don't have any mechanism for communicating deprecation. This is part of why I'd like to discourage using the PIP rules in our main repositories they are subject to disappearing and being replaced when a better packaged solution arrives.

We should go ahead with this change and not revert it.

@Achllle please make sure to also release a version for melodic and noetic to get better coverage.
@PymZoR If you're not covered by the above list. We can add the pip rule back for other platforms but it should be nulled for any supported platform for kinetic and newer that would conflict with the released ROS package.