unbundle colorama package

[marbu]

I propose to:

• remove bundled colorama package
• add it into requirements.pip instead

[tony]

Nice @marbu !

Colorama is in the realm where we'd be ok keeping it vendorized.

When vendorizing - several factors come into play. What comes to mind when / when not to vendorize an external lib:

• How big is the package?
• What's it's purpose?
• How often does it change?
• Is the maintainer open with development? (for instance, are they just uploading the package to Pypi with no VCS? Yeah, sometimes it happens!)
• Does this save or create a headache for package maintainers (ports, deb, rpm, etc.) who wants to create packages?
• Is the API interfaces and behavior stable?

To put it into context, pip vendorizes colorama as well https://github.com/pypa/pip/tree/develop/pip/_vendor/colorama.

Colorama is small. It doesn't change much. It's nice to have it inside the package because it saves a download.

Frankly I'd be more inclined to invite upgrading the vendorized version of colorama to 0.3.3. Would you be willing to do that?

On that note, if good reason can be given - I'm open to hearing the benefits in favor of de-vendorizing colorama.

[marbu]

Thank you for your explanation! I will try to explain my reasoning below as well.

I'm actually working on packaging of tmuxp with hope to have it included into future fedora release, and so I need to follow Packaging:No Bundled Libraries rule. And from this point of view, not vendorizing colorama would make it easier for me, as:

• Either: I don't have to ask Fedora Packaging Committee for an exception which would be likely rejected
• or don't have to maintain this patch downstream while other distro's packagers would need to do the same

Moreover there already is fedora package or debian package for colorama.

While I'm not familiar with details of Debian packaging policies, I guess they have similar policy in place, so de-vendorizing colorama would make packaging easier for Debian and other distros as well.

I understand that sometimes there are legitimate reasons for vendorizing packages, but here I feel that the cost of the change is quite small: the colorama is already available on pypi so it can be easily installed with pip, which is the default installation method of this project anyway (so from the user point of view, there is no change).

When you say that colorama doesn't change much, it implies that the API is stable. This is another reason for de-vendorising as there is little risk of breaking something over time.

And last but not least, de-vendorizing colorama would make it easier for you to maintain the project, as you wouldn't need to update vendorized code now and then.

Speaking of pip, I think that this project is in quite unique position. Since it's a python package manager, it can't easily install it's own dependencies by itself so bundling some dependencies actually makes sense as it tries to overcome the chicken - egg problem.

[tony]

Thanks for articulating that. I thought vendorizing was ultimately doing a favor for packagers, apparently my belief was mistaken.

What does fedora do for pip? Pip has vendorized colorama.

I think I'm more inclined to merge this then. It's late here, I will come by and check on this tomorrow.

[tony]

Makes sense to me. Way to go @marbu!

[marbu]

Thanks!

[tony]

@marbu Thank you! This is live in v0.9.0. 👍