Packaging a python package that requires source to be included

For Developers
1

Hi folks,

I've been working to get duplicity (http://duplicity.nongnu.org) packaged and running on OpenWRT. As part of this, I've dusted off and updated the package builds of librsync (required by duplicity) and rdiff-backup (low hanging fruit, also dependent on librsync). Also, I've added packages for python3-paramiko, python3-pynacl, and python3-scp.

What I'm running into is some unexpected-for-OpenWrt behavior in duplicity -- it has a number of backends incorporated to use different transport mechanisms. It discovers them by looking in it's own installation directory for "*backend.py" files.

By default, python packages get the bytecode pyc files included only. This means, the duplicity package generated looks for it's own backends and doesn't find them. If I install the -src variant of the package too things do seem to function as expected.

So..the question is, is there a reasonable way to make the default python package include the source files too? Looking at python-package-install.sh, I don't see any conditional behavior for the removal of .py files. So I'm looking for advice as to how to most palatably package this.

It would seem options are:

  1. Custom install step -- it would basically be a copy/paste of steps in python-package-install, minus the removal of the .py files.
  2. OpenWrt diffs to duplicity source to change the backend discovery to something not dependent on .py files.
  3. Make the duplicity package dependent on duplicity-src.
  4. Anything else I'm missing? Other package precedence?

Option 1 would provide the best "user experience", but a wholesale copy/paste of install steps like this seems undesirable. Option 2 may be workable, but right now no diffs are otherwise to build this package, so I'd be a little concerned this would make it more brittle for up revs.

Option 3 is a bit hacky from a user experience perspective -- one might not expect to be required to install the src package, but it does work.

Any precedence for behavior like this in other packages? I'm happy to pull together a pull request with the above changes once the packaging solution is considered palatable.

Thanks,

- Joe