Release 0.920 planning

[ilevkivskyi]

I will be releasing mypy 0.920 soon. The release branch will be cut at a7d6e68. Please post here any PRs that need to be merged and cherry-picked.

[ilevkivskyi]

This is the release branch https://github.com/python/mypy/tree/release-0.920

[ilevkivskyi]

#11168 needs to be CP'ed (done).

[zevisert]

❤️ I would like to see 6eafc5e included, which I think -- just judging by the dates -- should already be. I was surprised to find today, that there's no release already bringing the fix for tuple[T, ...] raising Unexpected "..." for ^3.9

[hauntsaninja]

That will be included! :-) The release branch is linked above / the cutoff date from master is Sept 20

[Zac-HD]

It's well after Sept 20, but I'd love to see 9aaeef5 in the next release - mypy xor torchtyping is a painful dilemma.

[mr-c]

@ilevkivskyi Will there be an official release candidate for 0.920 that I can test in my role as the Debian maintainer of https://packages.debian.org/sid/mypy or shall I make my own snapshot of https://github.com/python/mypy/tree/release-0.920 for testing?

[mr-c]

I made a snapshot of febec71
from https://github.com/python/mypy/tree/release-0.920

and I get this error

MYPY_USE_MYPYC=1 dh_auto_build
	pybuild --build -i python{version} -p 3.9
I: pybuild base:232: /usr/bin/python3 setup.py build 
Parsed and typechecked in 38.693s
Compiled to C in 0.000s
mypy/modulefinder.py:440: error: Argument 1 to "load" has incompatible type "TextIO"; expected "BinaryIO"
mypy/config_parser.py:172: error: Argument 1 to "load" has incompatible type "TextIO"; expected "BinaryIO"

[emmatyping]

@mr-c That is almost certainly related to #10893, but I'm not sure why you'd be getting that error as the newest commit in that branch pins tomli.

[mr-c]

@mr-c That is almost certainly related to #10893, but I'm not sure why you'd be getting that error as the newest commit in that branch pins tomli.

Thanks! I had packaged the latest release of tomli v1.2.1 in Debian, so that's probably why I had that problem https://tracker.debian.org/pkg/python-tomli ; I'll cherry-pick that PR into a local patch for my preparatory packaging of mypy 0.920

[emmatyping]

Also while I'm thinking about it we should probably mention #9275 being on the horizon in the 0.920 release notes.

[ilevkivskyi]

@Zac-HD sure, I will CP tomorrow.

@mr-c We usually don't do RC, but I can let you know few days before the actual release so you can test the source/binaries.

[mr-c]

@mr-c We usually don't do RC, but I can let you know few days before the actual release so you can test the source/binaries.

Thanks, that works!

[ilevkivskyi]

@Zac-HD Actually I tried cherry-picking but somehow I got a big merge conflict. I don't have much context, so not sure how to resolve, I think it would be better if you can make a CP PR against the 0.920 branch and I will merge it.

[emmatyping]

Since there is a new pip, for upstream packagers we should probably also cherry-pick #11356 so that the tests aren't broken on rolling release distros.

[ilevkivskyi]

Yes, just cherry-picked that.

[srittau]

#11531 (typed-ast bump) should go in for compatibility with tools that depend on typed-ast unconditionally, as typed-ast 1.4 breaks on newer Python 3.9 versions.

[hauntsaninja]

We should cherry pick #11531 , since it'll allow users of Python 3.9 and 3.10 to check Python 2 code. More generally, is there anything I can do to help with the release?

[JukkaL]

@hauntsaninja Double checking that all new features added since 0.910 are documented would be helpful, or just leaving a comment here if you find something that is not documented (clearly enough). Also, style and grammar checking documentation changes since 0.910 would be great. I'm planning to help with these, but I don't have the bandwidth to do this in the next several days at least.

[JukkaL]

FWIW, I and @ilevkivskyi have some ideas about speeding up the release process. I hope to have the next release after 0.920 out within about a month of 0.920 being released.

Also, we could document the steps we have for writing the release blog post and make it possible for everybody to help with that.

[JukkaL]

#11532 should also help speed up the release process. Any help with this would be greatly appreciated!

[hauntsaninja]

I recommend cherry picking the following docs updates:
#11161
#11174
#11186
#11262 (includes a small code change)
#11281

I recommend changing docs/requirements-docs.txt to:

sphinx>=4.2.0,<5.0.0
sphinx-rtd-theme>=1.0.0,<2.0.0

(make this change directly, don't try to cherry pick from master)

#11498 makes two small spelling fixes to docs (but the code changes don't apply cleanly to the release branch).

[JukkaL]

Could we also cherry-pick #11632, which fixes a frequently reported crash?

[ilevkivskyi]

OK, cherry-picked this one and also #11630

[intgr]

Aside from double-checking documentation (#11158 (comment)), are there any more known release blockers? There doesn't seem to be any issue label such as "blocker" or "regression".

[JukkaL]

I don't think that there are any remaining release blockers. We just need to finish the release process, and finish a release blog post.

[JukkaL]

Maybe we should cherry-pick #11738 and update the trove classifiers to support Python 3.10?

[ilevkivskyi]

OK, I cherry-picked #11738 and also #11729. Could you please make a PR to update the trove classifiers?

[hauntsaninja]

#11747 for trove classifiers

[alippai]

#11729 means dropping python 3.6 support, should we update the mypy setup.py as well?

[ilevkivskyi]

Hmm, @JukkaL I think we should keep 3.6, so I guess I will need to revert this cherry-pick. @alippai Thanks for pointing this out!

[hauntsaninja]

#11729 does not imply mypy dropping Python 3.6 support, since it just changes the allowable upper bound with no change to lower bound. If you python3.6 -m pip install 'tomli>=1.1.0,<3.0.0' it will happily install tomli 1.2.3

[ilevkivskyi]

OK, great then!

[ilevkivskyi]

Cherry-picked also #11747, thanks @hauntsaninja!

[JukkaL]

Cherry-picked #11749.

[ilevkivskyi]

I just uploaded https://pypi.org/project/mypy/0.920/ Could everyone please check if it works on their platforms?

[ichard26]

Works without issue type checking and mypyc compiling psf/black under Ubuntu 20.04.03 x86-64 CPython 3.8.5 :)

[arnimarj]

A mypy upgrade for mypy-zope just passed Shoobx/mypy-zope#59

[pranavrajpal]

I'm not seeing any apparent crashes or installation failures on WSL or Windows.

mypy --version did appear to take a long time the first time I ran it on Windows, but I haven't been able to reproduce that more than once so I'm guessing there's some unrelated issue (maybe a Windows version of #8055?).

[hauntsaninja]

Seems to be working well across platforms in a PR to typeshed; thanks for all the work to get this out!

Btw, I noticed that the blog post is out, but http://mypy-lang.org/ doesn't yet show it

[pranavrajpal]

I'm not sure if this is the right place to mention this, but I noticed a typo in the blog post. In the "Making a Variable Optional in an Else Block" section, "alllows" should be "allows".

Out of curiosity, is there a github repo where I can look at the raw markdown and/or send a PR for the blog posts?

[mr-c]

Congratulations on the release; and thanks!

For building mypy 0.920 on Debian, we are getting test errors that seem to be related to Python 3.10.1, even after applying #11752 ; are there other commits we should pull down?

Full log of test errors is at https://gist.github.com/mr-c/80454ac454c1d69d57a093ff0e8bd53e

[cdce8p]

For building mypy 0.920 on Debian, we are getting test errors that seem to be related to Python 3.10.1, even after applying #11752 ; are there other commits we should pull down?

@mr-c Please try applying #11756 as well. I missed some errors the first time.

[mr-c]

For building mypy 0.920 on Debian, we are getting test errors that seem to be related to Python 3.10.1, even after applying #11752 ; are there other commits we should pull down?

@mr-c Please try applying #11756 as well. I missed some errors the first time.

That works, except for one test which I will probably skip manually; thanks!

______________________________________________________________________________ testErrorOutput ______________________________________________________________________________
[gw3] linux -- Python 3.10.1 /usr/bin/python3.10
data: /tmp/autopkgtest.dMe019/build.ZT9/src/mypyc/test-data/commandline.test:104:
../autopkgtest.dMe019/build.ZT9/src/mypyc/test/test_commandline.py:73: in run_case
    assert_test_output(testcase, actual, 'Invalid output', expected=expected)
E   AssertionError: Invalid output (/tmp/autopkgtest.dMe019/build.ZT9/src/mypyc/test-data/commandline.test, line 104)
--------------------------------------------------------------------------- Captured stderr call ----------------------------------------------------------------------------
Expected:
  test.py:7: error: range() step cannot be zero (diff)
  test.py:10: error: break inside try/finally block is unimplemented (diff)
  test.py:12: error: continue inside try/finally block is unimplemented (diff)
  test.py:21: error: Only assignment to variables is supported in class bodies (diff)
  ...
Actual:
  /tmp/mypy-test-xlktckcc/tmp/build/setup.py:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives (diff)
    from distutils.core import setup            (diff)
  test.py:7: error: range() step cannot be zero (diff)
  test.py:10: error: break inside try/finally block is unimplemented (diff)
  test.py:12: error: continue inside try/finally block is unimplemented (diff)
  test.py:21: error: Only assignment to variables is supported in class bodies (diff)
  ...

Alignment of first line difference:
  E: test.py:7: error: range() step cannot be zero...
  A: /tmp/mypy-test-xlktckcc/tmp/build/setup.py:1: DeprecationWarning: The di...
     ^

[JukkaL]

I'm not sure if this is the right place to mention this, but I noticed a typo in the blog post. In the "Making a Variable Optional in an Else Block" section, "alllows" should be "allows".

Updated.

Out of curiosity, is there a github repo where I can look at the raw markdown and/or send a PR for the blog posts?

That's not public right how. I have plans to move the blog posts into a public repo at some point.

[ilevkivskyi]

A little update here: I just uploaded a minor bugfix release http://mypy-lang.blogspot.com/2021/12/mypy-0921-released.html

I think this is issue can be closed now. Please feel free to re-open if there are some regressions that need to be released.