Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundled libs in invoke/vendor #204

Closed
omadjoudj opened this issue Jan 11, 2015 · 4 comments
Closed

Bundled libs in invoke/vendor #204

omadjoudj opened this issue Jan 11, 2015 · 4 comments
Labels

Comments

@omadjoudj
Copy link
Contributor

@omadjoudj omadjoudj commented Jan 11, 2015

Hello,

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

Thanks.

@bitprophet
Copy link
Member

@bitprophet bitprophet commented Jan 28, 2015

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 =/

@bitprophet
Copy link
Member

@bitprophet bitprophet commented Jan 28, 2015

Referencing #4 as well, though most of the articulated arguments are in that blog post.

@omadjoudj
Copy link
Contributor Author

@omadjoudj omadjoudj commented Feb 13, 2015

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.

@bitprophet
Copy link
Member

@bitprophet bitprophet commented Dec 12, 2016

Implemented in #412 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.