Make HotRunner call pub get automatically if the pubspec is out of date. #19183
Conversation
|
@devoncarew should this also add a new |
There was a problem hiding this comment.
Two questions about the stdout output and whether to run on every reload and restart or just on restarts.
In terms of testing, you could investigate the integration tests in https://github.com/flutter/flutter/tree/master/packages/flutter_tools/test/integration; @DanTup has added several for reload + debugging, so if unit testing isn't feasible, that would be a good option.
| @@ -282,7 +300,7 @@ class HotRunner extends ResidentRunner { | |||
| } | |||
|
|
|||
| Future<bool> _updateDevFS({ bool fullRestart = false }) async { | |||
| if (!_refreshDartDependencies()) { | |||
| if (!await _refreshDartDependencies()) { | |||
There was a problem hiding this comment.
Do we want to run pub if dirty on reload, or just on restart? Only on restart feels slightly more natural to me, as its handling a bigger change.
There was a problem hiding this comment.
The issue I was trying to fix specifically requests hot reload, and I think I agree with that: hot reload should incorporate any changes that it can. In my mind, the main conceptual difference between the two should simply be if you want to preserve state or not (in practice, of course, you are required to restart for other reasons too).
There was a problem hiding this comment.
Gotcha. We could also message on reload (You pubspec is out of date, perform a hot restart to get new dependencies), but users would then just need to perform the restart. So, this change looks good for both reload and restart.
|
|
||
| try { | ||
| // Will return immediately if pubspec.yaml is up-to-date. | ||
| await pubGet( |
There was a problem hiding this comment.
Can you confirm that this does print some appropriate message (so the user knows that a pub get is running)?
There was a problem hiding this comment.
Well.. it wasn't. This turned out to be because hot reload calls startProgress on the logger, and then pubGet does the same, and the daemon code uses a custom logger that completely ignores nested progress messages.
I've changed it to print nested progress messages again. You appear to have disabled them (#6677) to make the messages for hot reload and hot restart the same, however, so that might not be the right answer. Other alternatives would be to add an argument to tell startProgress to not ignore specific messages, or to change pubGet to not start its own progress (but that's nice to have on the command line).
There was a problem hiding this comment.
Ah, Nov 3, 2016. I think I was trying to address having many small progress items flash by, instead of having a single, unified progress.
IDEs would likely need to upgraded to handle nested progresses, but let me take a look through the PR.
There was a problem hiding this comment.
The progress bar is an indeterminate bar on IntelliJ, and it does actually seem to work (it turns on the indeterminate progress bar in the status area when the reload starts, and turns it off when it's done). For this case, there are only a couple of steps (running pub get, and syncing to the device), but I imagine there could be some where it was a lot of steps flying by.
Of course, it looks fine in the IntelliJ "Run" console output, and on the regular command line.
There was a problem hiding this comment.
Sounds good! Two steps, where they both don't just flash by, isn't a concern for me. I would just get concerned if we had many very short steps - the text would flash by too quickly for users to read.
|
|
||
| try { | ||
| // Will return immediately if pubspec.yaml is up-to-date. | ||
| await pubGet( |
There was a problem hiding this comment.
should this also add a new PubContext value that describes how the pub get is being called?
Ah, possibly, based on what the current message says? We may want it tweaked so it says slightly different things based on an initial flutter run vs. a restart.
2f47172 to
4b0322e
Compare
This adds a call to 'pub get' if the pubspec.yaml is out of date wrt the .packages file when a hot reload is requested.
This PR is missing tests, however there is a dearth of tests for
HotRunnerbecause of the effort needed to set up an appropriate test environment. I'd like to fix that, but I think it's out of scope for this PR.Fixes #15879