-
Notifications
You must be signed in to change notification settings - Fork 939
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
feat: Let mesa runserver detect server.py as fallback #2015
Conversation
Tested manually:
|
Performance benchmarks:
|
Performance benchmarks:
|
@EwoutH do you know why did the performance comment happen twice? |
Once for opening the PR, once for marking it "Ready for review" |
I will take a look this evening or tomorrow. This is exciting. |
Can someone write a 3 sentence summary of this PR for the 2.2.5 release notes? (I would find it really useful if each PR message is readable in isolation. Just from the PR message I would like to understand what a PR does/solves/enhances/adds without having to dig into code or other issues) |
This is a new feature, even though @tpike3 said that further older models used server.py instead of run.py, but the feature wasn't present in 2.2.4 nor 2.1.x and 2.0.x. And so can't be included in a patch release. |
But I suppose it is fine if the feature has once existed in the past? @EwoutH updated PR description. Up to you if you want to include in 2.2.5 or not. |
Wait, I just realized of a bug in this PR
The code says that both run.py and server.py are executed in sequence instead. Not sure why I didn't see it. Let me double check. |
I see why the code passed my manual tests: it is because the first run call blocks the execution of the next line indefinitely, and the user always presses |
This is part of the ongoing effort to obsolete run.py, to simplify the current model template. run.py always contains only 2 lines and hasn't been used for any customization, and so should be merged back into server.py. For discussion, see #1269.