Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 0.700 planning #6588

Closed
JukkaL opened this issue Mar 25, 2019 · 16 comments
Closed

Release 0.700 planning #6588

JukkaL opened this issue Mar 25, 2019 · 16 comments

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Mar 25, 2019

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.

@ethanhs
Copy link
Collaborator

ethanhs commented Mar 26, 2019

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

EDIT: These are both merged.

@JukkaL
Copy link
Collaborator Author

JukkaL commented Mar 27, 2019

I've cut the release branch.

@msullivan
Copy link
Collaborator

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
Copy link
Collaborator

Two cherry-pick requests:

@msullivan
Copy link
Collaborator

And another, though it still needs some finalization:

@msullivan
Copy link
Collaborator

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

@gvanrossum
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Collaborator

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

@gvanrossum
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Collaborator Author

JukkaL commented Mar 29, 2019

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

@JukkaL
Copy link
Collaborator Author

JukkaL commented Mar 29, 2019

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
Copy link
Collaborator

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
Copy link
Collaborator Author

JukkaL commented Apr 3, 2019

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

@JukkaL JukkaL closed this as completed Apr 3, 2019
@msullivan
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants