Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Don't passthrough_errors unless instructed. #2006
If you merge this, we are back at square one, the passthrough errors option for flask will be broken again. Flask will passthrough errors all right, but then werkzeug will block them.
I see now how the change in cli.py is a problem, but the change in app.py is perfectly fine and can/should stay. Why is there a need to undo that one as well?
As for the cli.py change, would it make sense to adapt that change to only set passthrough errors when the app is loaded eagerly? That seems doable and will only leave passthrough errors incorrectly set when the reloader is used, and that to me is fine, since the reloader and a debugger are normally not used together.
IMO it's problematic to have two different behaviors for the Flask command and app.run. They should behave the same as far as possible.
On 6 September 2016 18:14:30 CEST, Miguel Grinberg email@example.com wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Uniform behavior is good, but in this case you are uniformly applying the wrong behavior, so it isn't a great solution IMHO.
For starters, let's agree that the use of
I do not agree that it is a good idea to break passthrough errors for
I think we can leave
What's left are the lazy loading cases, which in general are the cases where debug mode is enabled, or at least when the reloader is on. The usefulness of passthrough errors in these cases is debatable. I have never used passthrough errors in conjunction with Flask's debug mode myself. I think addressing passthrough errors in this case is much lower priority than the other cases, so I would leave an issue open for that. I'm happy to think about addressing this case as well.
On Tue, Sep 06, 2016 at 09:14:30AM -0700, Miguel Grinberg wrote:
Currently we already have a very complex net of dependencies for the default
The upside for those is that in the end this chain reaction of setting
I know that this PR breaks the usecase of attaching a debugger, but I consider
@untitaker do you have a list of these? I'm not aware of any broken use cases outside of this whack-a-mole situation we are in now, where we fix an issue, and a new one pops out. As far as I'm aware, the only problem with current master code is #2005.
Sep 6, 2016
1 check passed
@untitaker @miguelgrinberg A thought--this issue contains a lot of thoughtful back and forth between two folks who deeply understand the underlying issue... but the discussion/disagreement/decision all happened in a single day.
In general I'm in favor of being decisive and keeping moving--we've got plenty of issues in the tracker where I wish a decision had just been made and moved forward. However, this particular issue strikes me as one that might have been better to sit on for 2-3 days before making a final decision. You're both responsive and not going to abandon the issue, and you're clearly disagreeing w/o getting upset. That's fine, healthy even for the community.
Historically when I've disagreed about a solution with another engineer who was knowledgable about the problem space, a night or two of sleep gives everyone's brains a little more time to ponder. Sometimes we're still at the same place and have to just decide, but other times we realize the problem constraints are slightly different than we'd originally thought which makes the better solution obvious. Not a big deal, a thought for the future.
@jeffwidman Thanks for writing this. @untitaker can correct me if I'm wrong, but I believe the action that he took to address this issue was not a final decision. I see it more as an interim solution. His choice was to leave a known bug in the code, instead of keep trying to fix it and risk causing other problems, which we all agree is a possibility, given how tricky this issue demonstrated to be. I would not have done what he did, but I can understand the choice and as you say, I'm not upset. I think both agree there is a problem that needs a fix. I am thinking about how to solve it in a safe way and will bring it here for review once I have it.