Python / lib package handling

[wolfv]

One issue I had with automatically generating (conda-forge) recipes before is that I had to manually figure out wether a package was a library with shared objects (in that case it's a good idea to add a run_exports) or wether a package is a Python package (in that case one needs to add python to host & run as dependency).
It would also be cool if we would know which packages can be noarch...

Maybe we could maintain a list with information about the packages?

Also one other issue I had with generating "conda-forge" conform packages was that the license info in ROS packages is somewhat limited (only a inexact specifier in package.xml, and often no LICENSE file).
I used a tool that heuristically determines the license from the license text found in the source code and that also finds a source file with the license text at the beginning as is commonly found.

I think all those things might not be so important if we go for our own "distro" though?

[wolfv]

maybe we should add run_exports with pin_subpackage(exact=True) to all recipes, so that the distribution as such stays consistent.

This would also mean that with every change, all dependent packages need to be rebuilt (but @tfoote explained to me that that's the way it is with ROS right now).

[tfoote]

I would recommend to trigger downstream by default. We are working to add abi compatibility indicators to the package.xml format but it's not mature yet and the safest assumption is to rebuild downstream if the maintainer hasn't indicated otherwise.

[wolfv]

cool great to hear that you're working on this. that's going to be a nice addition.

with the way vinca works right now, I think triggering downstream by default should be quite easily doable 👍.

If we could find a place to get some CI time we could run vinca periodically to make a ROS channel for conda... do you think OSRF could help us with resources there (ie. access to CI machines)?

Btw. did you get my emails? :)