I'm packaging pyinvoke for Fedora (preparing for Fabric 2.x), and the policy does not allow bundled libraries, so I'm wondering if we could remove the libraries in ./invoke/vendor and replace them with disto/pypi provided one.
Note that Debian has the same policy, so this might help Debian packager too.
Here's the patch against 0.9.0 branch: https://athmane.fedorapeople.org/pkgs/invoke-0.9.0-remove-bundled-libs.patch
The rationale for vendorizing is here: http://bitprophet.org/blog/2012/06/07/on-vendorizing/
It's far from a perfect solution and I've definitely second-guessed it at times, but for now the benefits still outweigh the costs.
I'm open to massaging things to make flipping between vendor/no-vendor easier, e.g. tweaking sys.path in the top level __init__ such that we don't need to refer to vendor.* - though this feels fraught with peril. (e.g. it means users with dep conflicts would encounter problems that we'd be unable to work around).
Other ideas welcome too. Most of what I can think of is either kinda gross like the above, or not feasible for what I think your needs are (e.g. we could honor an env var at import time and conditionally import from vendor or not - but then that requires all users of your distributed version to have this env var set, which is probably difficult to manage.)
I know there are other Python libs which aren't budging on the vendor issue; is distro policy for them to just move the burden of un-vendorizing into patches like the one you linked?
tl;dr I don't want to be difficult for OS vendors but I also do have reasons to vendor =/
Referencing #4 as well, though most of the articulated arguments are in that blog post.
I'm in favor of simplifying distro packager's patches by making flipping between vendor/no-vendor easier, that reduce the chance of rebasing the patch very often.
Let me know if you need help with this.
Thanks in advance.
Changelog re #204, re #412, closes #204
Implemented in #412 !