Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
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
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 =/