Hi Sébastien, > Ideally, your setup.py wouldn't include versioned dependencies
That would mean that `pip install mitmproxy~=0.18` won't work in a year from now because one of our dependencies released a backwards-incompatible release in the meantime. From a Python/pip perspective, not specifying a upper bound seems to be the worse option. > 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". requires.io just mirrors the information in setup.py on master ( https://github.com/mitmproxy/mitmproxy/blob/master/setup.py), if that is helpful to you. :-) > Maybe the best course of action for Debian is to not use upper boundaries on dependencies at all ? It sounds like we either have a scenario where (1) mitmproxy becomes uninstallable if someone updates a dependency in Debian between mitmproxy releases that was not present at our release time or one where (2) mitmproxy may still be installable, but it potentially just breaks due to backwards-incompatible changes within the dependency. If I understand things correctly, there's no automated testing that would alert someone in either case, so (2) may be preferential for Debian as that it would simply break less often (although possibly in more subtle ways). I don't know how Debian handles this generally and what the best practices are for this. >From our perspective, the best ways seems to be to just hand out a single package that comes with everything up-to-date (e.g. a virtualenv or a binary), but I understand that this is not what Debian is looking for. > 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 :) With requires.io monitoring and our CI systems we usually see those a couple of days after releases are pushed to PyPI. No offense, but the updates in Debian are usually happening well after that, so there is not much added value to us. Thanks for the good intentions though! Cheers, Max On Thu, Dec 15, 2016 at 11:19 AM Sébastien Delafond <[email protected]> wrote: > 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 >
