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

Dear Ian, Thanks for your detailed reply! However, I think you have not addressed my final question regarding the timeline of possible releases and having this fixed upstream. I allow myself to add some remarks inline. All the best! ~petr On 29 Jun 2015, at 20:43, Ian Cordasco wrote:

On Mon, Jun 29, 2015 at 1:24 PM, Peter Danecek 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. This is not exactly what I was saying, but I guess you are actually aware of this. You also may have missed the second part of the assumption.

In this particular case that /assumption/ is incredibly wrong. Apparently! This is what I am addressing here ;-) I still believe, projects based on other ones can never have control of everything and need to rely on good practice.

...

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. Well, this is only partly true. Macports can deal with different versions to some extent, but might do better at verifying Python version constraints. However, I doubt it is worth the effort. MP is not really about Python ports only and real issues are rare. Still, using version constraints extensive has the potential to create conflicts, independently how the package manager deals with it.

...

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. Thanks for the invitation. However, if time is available I'd probably focus on the projects I am already involved. Of cause, if I find issues with other projects, I am happy to contribute by reporting back, document issues or PR. However, releasing is probably beyond the scope.

...

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. Looking forward to this!