It would be nice if the packaging code was able to analyze included python code to determine the python modules it depends upon, the way we do for kernel modules and for shared library linking. We could likely implement this using the existing 'modulefinder' package that's in the python standard library, see http://docs.python.org/2/library/modulefinder for details on that. It could also potentially read the shebang lines for core python version, and potentially look at python packaging information (setuptools, egg-info, etc). Related: rpm feature request to do this at http://www.rpm.org/ticket/154, and attached egg-info analyzer script at http://aurelien.bompard.org/projects/files/misc/pythondeps.sh The counter-argument for this would be that it's too much magic, and is too implicit, violating the Zen of Python, but if there's a sufficient improvement in usability, and I think there is, it may be worthwhile. As Paul Eggleton pointed out on IRC, you can end up in a sad build/test cycle adding various rdepends for various modules until you're able to run the thing you're writing a recipe for, which could be quite frustrating for the user.
Starting work on this.
As I started implementing the metadata aspects of this, duplicating the pattern implemented by both shlibs and the pkgconfig dependency code, I started wondering if we shouldn't have a more general mechanism that one can hook into to add new types of automatic dependencies. My current thoughts on that: https://gist.github.com/kergoth/5768039. Any opinions on that?
https://github.com/kergoth/meta-package-auto-deps has the last work I did on this about 4 months ago. I'm going to look into finishing this work (potentially reworking what I was playing with before), and see about submitting for comments and review, hopefully in the next week or two.
I think this will be a useful feature, but we need to determine the form it should take. I think it should be an explicit opt-in choice, not an automatic one, given the amount of manual massaging of the output needed. Shifting to a future milestone.
Implemented by bug 7036 as a part of the recipe creation process rather than packaging process, to avoid the concerns with that which I brought up in this issue.