Pycodestyle: Release to PyPI, now and more frequently

Created on 24 Dec 2019 · 15Comments · Source: PyCQA/pycodestyle

Please release now and more frequently! As per PEP 602, Python now has an annual release cycle, and pycodestyle should really try to keep up!

There has been no supporting release of pycodestyle since Python 3.8 was released. There have already been essential change for merged that users are waiting for, e.g. https://github.com/PyCQA/pycodestyle/pull/879

The last release was about a year ago! For a comparison, please see how much more frequently other PyQCA tools release, i.e. several times a year!

Source

impredicative

👍15 👎1

Most helpful comment

fwiw, I'm planning to do this -- see https://github.com/PyCQA/pycodestyle/issues/911

asottile on 6 Mar 2020

❤3

All 15 comments

For a comparison, please see how much more frequently other PyQCA tools release, i.e. several times a year!

For comparison, look at the contribution activity on those tools as well. There are people actually maintaining them.

I see no offer to step up and actually help just a demand for more work from people who don't have the time to do it.

sigmavirus24 on 16 Jan 2020

👍1

@sigmavirus24 Releasing frequently doesn't really take a lot of effort, does it? In any case, why was this issue closed without any release? How are users supposed to track it if it's closed? What is the point of all the user contributions if there won't be a routine release? It doesn't make any logical sense.

impredicative on 16 Jan 2020

👎3 👍1

Releasing frequently doesn't really take a lot of effort, does it?

It _does_ take time and effort. A good faith release requires verification beyond CI since so often things slip by both contributors and reviewers.

In any case, why was this issue closed without any release?

Because releasing right now would neither be secure nor timely.

How are users supposed to track it if it's closed?

This isn't an issue to track a specific release. This is a guilt trip for not having enough time and having found no one willing to step up to help despite multiple attempts.

What is the point of all the user contributions if there won't be a routine release?

I don't know. Is fixing things for the next release pointless?

It doesn't make any logical sense.

Well, I'm glad to see you're civil, respectful, and aware of how your actions and words contribute to maintainer burnout.

sigmavirus24 on 16 Jan 2020

👍1

@sigmavirus24 Thanks for this very helpful module!
I can volunteer a few hours to help in the next release (running tests, whatever you need).

FWIW, In the meantime I'll be using https://github.com/PyCQA/pycodestyle/commit/d69c15eb7ecf77e94988fb55207a78936b48079c in my day to day coding (I have vim setup with YCM/syntastic calling into flake8).

I also may mention that one can simply pip install the current master from git if one badly wants a feature.

pip install --upgrade git+https://github.com/PyCQA/pycodestyle.git

Works flawlessly on my ubuntu, your mileage may vary on a consumer (as opposed to developer) machine on windows though.

Perhaps this could be added to the README given the number of complains I've seen here (and I didn't look for a long time...)? I can do a PR if you want.

jmarrec on 14 Feb 2020

👍1

It does take time and effort. A good faith release requires verification beyond CI since so often things slip by both contributors and reviewers.

In other words, this project does not have a reliable CI CD pipeline that anyone trusts. Maybe that's where the focus should've been for the past year. As it stands, this project is a black hole for PRs.

In summary, there is little reason to use this package anymore, since autoformatters like autopep8 (configurable) and black (even usable together) will fix a lot of PEP 8 issues, and pylint/pyflakes will highlight any residual PEP 8 concerns.

impredicative on 14 Feb 2020

👎4

In summary, there is little reason to use this package anymore, since autoformatters like autopep8 (configurable) and black (even usable together) will fix a lot of PEP 8 issues, and pylint/pyflakes will highlight any residual PEP 8 concerns.

this isn't really true -- for instance autopep8 uses pycodestyle to do its thing. pyflakes also doesn't check anything related to pep8 -- its purpose is to catch syntax, unused things, etc. and never stylistic things.

the point being made about effort here is not that the CI is bad (it's actually pretty darn good!), it's just nearly impossible to handle every possible way that humans will write syntax and verification of a new release requires careful consideration across lots of codebases in order to be confident in things

asottile on 14 Feb 2020

it's just nearly impossible to handle every possible way that humans will write syntax and verification of a new release requires careful consideration across lots of codebases in order to be confident in things

That's what rc releases are for, aren't they? numpy uses them, for example. In contrast, this project doesn't even have dev releases anymore like it used to.

impredicative on 14 Feb 2020

the dev and alpha releases were special for major transitions (the package used to be called pep8 and those were the "make sure the new name works" releases) and were not a regular occurrence

we of course could do more pre-releases here, but at least in my experience people don't use them enough for the value prop to be there (pip ignores them by default unless you use --pre) so the value/effort trade off needs consideration

asottile on 14 Feb 2020

The objective there is to tighten the feedback cycle. Users who want expected bugfixes more than others will definitely pick and install specific pre-releases from PyPI, and they will be a vehicle for tightening the feedback cycle to discover any unexpected bugs that warrant improvements to the CI.

impredicative on 14 Feb 2020

they can also install pre-released code from git -- and then no release effort is necessary -- but we also don't see users do that all that often either!

asottile on 14 Feb 2020

look all I'm saying is I'd love for this to happen but you have to be realistic in the amount of effort that's necessary and demanding action from someone is not helpful. if you want the community to grow offer up some time and review some PRs, traige some issues, try out the current master on a bunch of code bases and provide meaningful feedback

asottile on 14 Feb 2020

I've switched to using d69c15eb7ecf77e94988fb55207a78936b48079c on a larger django codebase. Will open an issue, if I encounter any errors, but looks good so far.

max-wittig on 17 Feb 2020

Can you (or someone) please either point at a doc/issue/etc or articulate here what sort of requirements (or process) you would be looking for should someone wish to step up and help maintain/release pycodestyle more frequently.

I might be willing to, but before I get into aspects of "do you trust me" I'd want to have some good idea of what time commitment would be expected of me, and for what aspects of the release process/QA/etc I would be in charge of. Once I know that I can at least determine if I have the time and willingness to do so.

If not me, having this list would certainly help elicit that sort of thinking from others here.