On Dec/14, Maximilian Hils wrote: > Upstream here. If there's anything we can do to make your life easier, > please let us know! > > We only list known compatible versions in setup.py as we'd like to > avoid running around with the fire extinguisher every time one of our > dependencies publishes an backwards-incompatible release. We had too > many cases where $dependency broke `pip install mitmproxy` and this > seems to be the best way to avoid this. > > I am not very familiar with Debian packaging policies, so I don't know > what's the best way to handle this here. We're usually compatible with > the most recent version of every dependency at release time and we do > track our dependencies on master quite closely: > https://requires.io/github/mitmproxy/mitmproxy/requirements/?branch=master
Hi Maximilian, thanks for the input, it's really appreciated to have upstream authors chime in on bug reports even though they're not being directly solicited. Ideally, your setup.py wouldn't include versioned dependencies unless they are indicative of actual incompatibilities with mimtproxy. However, I can see where you come from, trying to protect yourself from backwards-incompatible releases. The requirements you provide at requires.io do help a bit, mostly in validating that some of the libraries packaged in Debian unstable right now won't break mitmproxy, but they still all include "<x.y". Maybe the best course of action for Debian is to not use upper boundaries on dependencies at all ? You state that "we're usually compatible with the most recent version of every dependency at release time", so in theory this should be fine. In case of backwards-incompatible releases, unstable would be somewhat on the front line, and thus would serve as an early warning to you when we encounter breakages :) Cheers, --Seb
