-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Dev Mode Config Settings #383
Comments
Just to be precise, this is what I imagine def run_server(self, debug=False, **kwargs):
debug_flask = kwargs.pop('debug_flask', debug)
self.set_debug_mode(debug=debug, **kwargs)
flask_run_args = {k: v for k in kwargs if k not in
['debug_flask', 'debug_serve_dev_javascript', 'debug_hot_reloading',
'debug_display_javascript_errors']
}
app.server.run(debug=debug_flask, **flask_run_args)
def set_debug_mode(self, debug=False, **kwargs):
# store the debug args in the instance so that we can use them when we
# serve the front-end JS config settings
self._debug_args = copy.copy(kwargs)
if 'debug_flask' in kwargs:
raise Exception('''
`debug_flask` can only be set when calling `app.run_server` as it
configures flask's dev server directly.
''')
debug_serve_dev_javascript = kwargs.pop('debug_serve_dev_javascript', debug)
debug_hot_reloading = kwargs.pop('debug_hot_reloading', debug)
debug_display_javascript_errors = kwargs.pop('debug_display_javascript_errors', debug)
# and all the other ones we end up having
# now actually do the things that these settings enable
# ... |
I don't like relying on kwargs that much, it tends to hide options to the users. Like the only time you gonna get auto-completion for the kwargs is in @chriddyp |
Here's what it would look like with def run_server(self,
debug=False,
dev_tools_debugger=None,
dev_tools_serve_dev_javascript=None,
dev_tools_display_javascript_errors=None,
dev_tools_flask=None, **flask_run_args):
debug_flask = debug if dev_tools_debugger is None else dev_tools_debugger
self.set_dev_mode(
debug=debug,
dev_tools_debugger=dev_tools_debugger,
dev_tools_serve_dev_javascript=dev_tools_serve_dev_javascript,
dev_tools_display_javascript_errors=dev_tools_display_javascript_errors,
dev_tools_flask=dev_tools_flask
)
app.server.run(debug=debug_flask, **flask_run_args)
def set_dev_mode(self,
debug=False,
dev_tools_debugger=None,
dev_tools_serve_dev_javascript=None,
dev_tools_display_javascript_errors=None):
# store the devtools args in the instance so that we can use them when we
# serve the front-end JS config settings
self._dev_tools = {
'dev_tools_debugger': dev_tools_debugger,
'dev_tools_serve_dev_javascript': dev_tools_serve_dev_javascript,
...
}
def with_default(some_value):
if some_value is None:
return debug
return some_value
dev_tools_debugger = with_default(dev_tools_debugger)
dev_tools_serve_dev_javascript = with_default(dev_tools_serve_dev_javascript)
dev_tools_display_javascript_errors = with_default(dev_tools_display_javascript_errors)
# and all the other ones we end up having
# now actually do the things that these settings enable
# ... |
I like That being said, I do like the sound of |
Some comments on the dev tools flags:
|
Ah, I see this is a mechanism to turn on everything or only turn certain debug options. Guess we just need people to be careful. |
Also, what is the best way to go about rolling this out? Should we add the config options in each PR as we merge them, or add them all at once and have the un-implemented ones do nothing? |
Yes it should be activated.
#369 is almost done and I added a |
Yeah, let's implement them one-by-one. I just want to make sure that we agree on:
Once we have consensus (add 👍 if you are OK with 1-4), we can introduce this pattern in our new PRs, one-by-one. |
Nice. I reckon this sounds like a solid foundation for building out dev-mode features on top of. Was definitely worth pausing to think about this. |
Excellent, thanks for chiming in everyone. I'll close this down now that we have consensus 👍 |
design based off of discussion in #383
* Fix for datepicker initial month Added current date as the last resort for the initialVisibleMonth property of the component in DatePickerRange.react.js and in DatePickerSingle.react.js (issue plotly#115) * Fix formatting * Fix DatePickerSingle formatting
I wanted to kick off a quick discussion about how we deal with dev mode settings. We've got a few PRs open that introduce new dev mode features and I want to make sure that we have the right abstraction in place.
For context, please read the thread from #369 (comment) and the "debug, dev, production" section in this issue: #312 and an issue by one of the flask developers about running debug mode: #16
Requirements:
debug=False
the default behaviour while includingrun_server
asgunicorn
won't userun_server
run_server
calls (enable_dev_mode
). That way, users using gunicorn in their dev env can just call this functionrun_server
as a dev environment, they shouldn't have to change their code before deploying it to the dev environment.run_server
or as an env variable.env
variable is too hard for our users.With these constraints, the only solution that I see is:
debug=True
command inapp.run_server(debug=True)
ends up doing two things:debug=True
intoflask.run(debug=True)
for auto-reloadingapp.set_debug_mode(debug=True)
debug_
:debug_flask=True
- This is the setting that allows users to turn on/off flask's debug environment (i.e.app.server.run(debug=debug_flask))
. This would include auto-reloading and the werkzeug debugger.debug_javascript_bundles=True
- This turns on/off the source maps/unminified bundles Add unminified components bundle support. #369debug_hot_reload=True
- This turns on/off hot reloading. Ifdebug_hot_reload=True
butdebug_flask=False
, then an error is raised (because we need flask's autodebugger - right?)debug_display_javascript_errors=True
- This turns on/off displaying the JS error messages in the front-end app (bubbling the error messages up from the browser console to the app) [WIP] Dash dev tools dash-renderer#64debug_display_python_debugger=True
- This turns on/off displaying the python debugger in the browser context and highlighting the error messages ([WIP] Dash dev tools dash-renderer#64). Ifdebug_display_python_debugger=True
butdebug_flask=False
, then an error is raised (because we need flask's autodebugger - right?)debug_display_callback_dag=True
- This turns on/off the graph of the callback visualdebug_hide_url_route_logs=True
- This turns on the HTTP request logging (and we turn it off by default) - remove werkzeug url print statements by default? #382<script id="_dash-config">{...}</script>
or w/e)Drawbacks:
app.run_server(debug=True)
and I instinctively write this whenever I create an app, so it's practically the default option.debug=True
was 1-1 with flask'sapp.server.run(debug=True)
. Now,debug=True
will set many other settings. This is OK, if a user needs to turn this off but they want something else on, they can do something like:app.run_server(debug=False, debug_javascript_bundles=True)
orapp.run_server(debug=True, debug_flask=False)
Naming:
debug_javascript
(which reads as "Debug javascript"), we'd have more specificdebug_server_dev_javascript
(which reads as "Debug mode: Serve dev javascript").Does this sound right @plotly/dash ? Sorry for holding things up here, but I want to make sure that we're laying down the right foundation 🚧
The text was updated successfully, but these errors were encountered: