Connexion: Vendorize dependencies?

[jmcs]

Description

After seeing #195 and taking the whole node left-pad debacle we should consider vendorizing at least some our dependencies like pip and requests, among others, do.

Pros

• We control the versions that we use, and are not dependent on what's is or is not in pypi;

• We are not vulnerable to packages getting removed or replaced on pypi.

  Cons

• We need to vendorize packages;

• We need to keep those packages updated.

[alexole]

I'd opt for explicitly mentioning version numbers, not more, not less. It's open source, sometimes new version breaks something.

[hjacobs]

My opinion: we should not vendorize packages, only if we really have a "risky" package among our dependencies, e.g. I would never vendorize Flask.

[jmcs]

@hjacobs what about "less known" packages like strict-rfc3339 (the page for this one doesn't even exist anymore http://www.danielrichman.co.uk/projects/strict-rfc3339.html) and jsonschema?

[rafaelcaricio]

_TL;TR:_ I vote to not vendor dependencies.

Our user base is not that broad and people that use Connexion use it in their own applications, as part of it, so they have control over what is going to be installed together. If Connexion was a CLI tool or something to be used as it-is I would vote to vendor the dependencies.

[hjacobs]

@jmcs even "less known" packages will (usually) not just disappear --- in the end we could always fork and upload a new package (I did this for at least one package where the maintainer was not responding to my Python 3 support issue / PR).

I guess Connexion apps will mostly be packaged e.g. as Docker images anyway (in Zalando definitely), so the risk that existing app versions break due to package removal is low.

[WouterVH]

:-1: for vendoring

[hjacobs]

Can we close this issue? Apparently the consensus is to avoid vendoring :smile: