On Fri, Sep 9, 2016 at 7:03 PM, Mads Kiilerich <[email protected]> wrote: > On 09/09/2016 06:38 PM, Thomas De Schampheleire wrote: >> >> > ... or we could desupport pytest < 3. But I guess this shows that it can >> > be convenient to keep the old version around a bit. >> >> I would rather argue that it is better to support a single version, then >> this mistake could not have happened... >> > > Why not? How would not supporting 2 have made 3 work?
The original problem that you detected (asserts in API tests not showing all details) would still have happened even if we had a single version. What I'm referring to is the fix that I made based on pytest 3 in my virtualenv. I had not considered the possibility that the function was new. Had there been just one version in setup.py, then my fix would work for everyone, there would be no chance that at some version in the supported pytest version range there was something different. > > Anyway, Andrew usually speaks up when we don't make our requirements as > relaxed as possible. I will let him decide ;-) Sure :) I think it makes sense to have relaxed version requirements for operational dependencies For dev_requirements I think it depends: pytest being an important requirement for our tests, a strict version looks right to me. But pytest-sugar, which is purely sugarcoating is different: here there is little (assumed) risk that a higher version would break. We don't directly depend on any of its features. /Thomas _______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
