Release 0.700 planning

[JukkaL]

I plan to release mypy 0.700 next Wed (Apr 3) and cut the release branch for 0.700 this Wed (Mar 27). This will be the first release with mypyc-compiled mypy available by default (on supported platforms).

Please add comments to this issue if you have any PR you'd like to be included. Ideally those PRs should be landed before the release branch is cut, to minimize cherry-picking.

[emmatyping]

I would appreciate it if #6592 was merged, and #6591 should be pretty low risk as well.

EDIT: These are both merged.

[JukkaL]

I've cut the release branch.

[msullivan]

I think we might want to write and cherry-pick some plugin hooks to support the Django plugin, which currently monkeypatches load_graph and State and so doesn't work with mypyc.

[msullivan]

Two cherry-pick requests:

• Pin tox version to 3.7.0 #6597 to fix CI on the release branch
• Produce a distribution named 'mypy' when built in mypyc mode #6596 to make compiled mypy packages

[msullivan]

And another, though it still needs some finalization:

• Add a get_additional_deps hook to Plugin to support django-stubs #6598 to allow the django plugin to stop monkey patching

[msullivan]

I am sorry about the relentless cherry-pick requests but we also might want to cherry-pick:

• Update pinned mypyc version to 0.0.1+dev.2724a1cf29462c012dccebe41d23… #6601 - update mypyc - previously mypyc had a specified dependency on the wrong version of typed_ast. ... though it seemed to work in practice OK, so maybe it doesn't really matter?

[gvanrossum]

1.3.0 introduced the new typed_ast synced with Python 3.7. Presumably mypyc itself doesn't use Python 3.7 features, so assuming this is only about mypyc's own dependencies, not those of the binary it builds, it's not the end of the world. It's also possible that somehow magically mypy's typed_ast dependency (which was updated) overrides here?

[msullivan]

1.3.0 introduced the new typed_ast synced with Python 3.7. Presumably mypyc itself doesn't use Python 3.7 features, so assuming this is only about mypyc's own dependencies, not those of the binary it builds, it's not the end of the world. It's also possible that somehow magically mypy's typed_ast dependency (which was updated) overrides here?

mypyc includes a vendored copy of mypy, and has to duplicate its typed_ast dependency. But we forgot, so it will use typed_ast 1.2.0 and a mypy that expects to be using 1.3.1. But since mypy doesn't use python 3.7, this might be fine?

[msullivan]

Sigh, and another one, though this one is definitely not my fault :P

• Ignore flake8 warnings about assert False #6602 to fix flake8 in the release branch CI

[gvanrossum]

mypyc includes a vendored copy of mypy, and has to duplicate its typed_ast dependency. But we forgot, so it will use typed_ast 1.2.0 and a mypy that expects to be using 1.3.1. But since mypy doesn't use python 3.7, this might be fine?

What I was trying to say is that yes, this should be fine, as long as mypyc is only used to compile mypy (since obviously it works). Or will mypyc users who don't use HEAD from mypy's master be stuck with this too?

And just to be sure the compiled mypy will still be using typed_ast 1.3.1 right?

[msullivan]

What I was trying to say is that yes, this should be fine, as long as mypyc is only used to compile mypy (since obviously it works). Or will mypyc users who don't use HEAD from mypy's master be stuck with this too?

I guess my concern is that this might cause trouble for people trying to reproduce the build, depending on their environment. But that's also pretty marginal because I'm not sure anybody has ever really done that.

And just to be sure the compiled mypy will still be using typed_ast 1.3.1 right?
Yes.

[JukkaL]

I've cherry-picked #6602, #6601, #6598, #6597, #6596, and a typeshed sync (#6604).

[JukkaL]

I wonder if we should document how to install a non-compiled mypy package as an alternative, similar to how we now have a separate compiled package. There's a risk that the compiled package doesn't work in all environments. If that happens, at least there would be a documented fallback until we fix the issue.

[msullivan]

That's a good idea. Should be as simple as specifying the --no-binarypip option, I think, which can be done on the command line or in requirements files.

[JukkaL]

...and the 0.700 release is out: https://mypy-lang.blogspot.com/2019/04/mypy-0700-released-up-to-4x-faster.html?spref=tw

[msullivan]

It may be worth releasing a 0.701 containing #6642 (stubgen crash under mypyc) and #6663 (update mypyc version to fix memory leaks)