Vendorizing Dependencies

[mion]

Hey, has anyone been working on the Vendorizing Dependencies section?

I've been waiting for it for quite a while, I basically got the hang of it by looking at ken's repos, but maybe there are some best practices I'm unaware of.

Would a pull request be accepted here? I could at least try to start writing something.

[tony]

@mion +1

A nice article that articulates vendorizing well: http://bitprophet.org/blog/2012/06/07/on-vendorizing/, it was written by @bitprophet. It could make an excellent addition to the guide.

Here's an example of vendorizing a dependency out of necessicity: pyinvoke/invoke#4. Also featured @bitprophet.

Colorama is vendorized a lot since it's low enough of a footprint not to be worth the footprint of adding as a dependency package. This would involve downloading a package from pypi. I'm not sure how every linux distro / port system handles python dependencies, but if dependencies are a complication there (they write handbook pages on it), vendorizing removes more headaches at the expense of a portion of code being out of sync with upstream.

[mion]

Thanks @tony! I'll have a look at those

One thing I always wondered: would it be a bad idea to check in your virtualenv within git?

[jhermann]

I did not try vendor: vendorize dependencies — DepHell 0.7.0 documentation yet, but it could make this way more accessible for the average dev.

[Adam-Antios]

I see that this issue is open since 2013 and it seems weird to me. Is there any update to it? Who is responsible for adding content? This question stems from my ignorance regarding the development of this book.

The printed book has this section filled. Why was not this section added to the online version as well?

[dbader]

@Adam-Antios It's an open-source community guide and anyone can suggest new content to be added by opening a pull request against the repo. If you're interested in fleshing out this section please go ahead :)