[code-quality] pep8 vs. flake8 incompatibility ...

[Ian Cordasco]

On Mon, Jun 29, 2015 at 1:24 PM, Peter Danecek <Peter.Danecek at ingv.it> wrote:
>
> Dear all,
>
> I am writing this mail, after I was directed to it in [1]. I note that the latest released versions of pep8 and flake8 are not compatible. This situation now persists for several month.

Correct, because pep8 has yet to release a version of software that
isn't broken in their 1.6 line. The last reliable version is 1.5.7.
1.6.0, 1.6.1, and 1.6.2 all break fundamental features of pep8 and
flake8.

> For the point of view of a project providing software packaging this is very unsatisfying. In particular, I am referring to Macports here [2]. Such project usually rely on the assumption that the latest released version tend to provide the best quality and user experience of a given software package, and if this should not be the case in one specific moment in time that problems are resolved timely.

The assumption that "the latest is the greatest" isn't always correct.
In this particular case that /assumption/ is incredibly wrong.

> In the case of pep8 vs. flake8, flake8 imposes constraints on the versions of dependencies. While lower bounds are perfectly fine, the upper bounds are problematic, because a perfectly working and well tested port would break by construction at any time later, when one of its dependencies is updated.

Packaging incompatibilities are the packagers concern. Macports should
be policing dependencies better than they are if they're having
problems with this. From Flake8's perspective, we are ensuring the
best user experience by implementing caps.

> I of cause understand the problems involved with parallel developments, but I would argue that one major goal of any project should be to remain compatible with the most recent versions of its dependency when ever possible or to release once major issues are resolved.

Given enough people working on all of the projects, that is definitely
a plausible and realistic goal. That isn't the situation here. If
you'd like to lend several hours of development work to all affected
projects along with others, I'm sure we could all be perfectly in
sync. Until then, please don't tell us volunteers how to spend our
time.

> In the concrete case, it looks like the relevant issue [3], which causes the version constraint on pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2) was actually resolved in [4] already some time ago, but this commit actually not released yet.
>
> On the other hand, constraints on mccabe (>=0.2.1,<0.4) & pyflakes (>=0.8.1,<0.9) are not founded on issues with concretely released software [1], but only hypothetical show-stoppers once these versions are effectively released [5]. I'd argue, such constraints shouldn't be around after all, but introduces only after test failure show evidence of any problem. Anyway, if develops want to insist on them [1], these should be relaxed timely after the release the relevant software. For pyflakes the release of version 0.9.0 dates back to 2015-05-31 [6], the release was acknowledged pretty timely in [7] and fixed in [8], but the change was no release thereafter yet.

Correct. That will be released in 2.5.0. There are other features and
bug fixes planned for 2.5.0 which have not been developed yet. If you
look at the issues filed against flake8 you'll notice this.

> So my question is now when this issues with conflicting versions, can be expected to be solved upstream. This is of particular relevance to understand if and how to solve the downstream issue in Macports [2], and if we need to foresee for any interim solutions.

Code wins. When a release can be prioritized, I'll prioritize it.
Unfortunately I cannot prioritize it right now, so feel free to patch
your Macports however you like, but please do not call it Flake8. All
bugs that are introduced by your downstream patches will not be
supported by me.