Give the user some control over progressbar invasiveness #348
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Progress reporting is useful but also has its drawbacks, like writing to the calling terminal when it's not in the appropriate state, or slowing down the process being reported on. This commit addresses both situations: 1. a set of 3 configuration variables is introduced with which the user can control (via macports.conf) after how long the progressbar should appear, if it should also show indeterminate progress (aka "we're busy") and what operations should report progress in addition to the traditional ones (fetch, build, destroot). The defaults for these are the current hardwired settings. The "also_for" setting is designed to be a list that currently only accepts "de/activation" for the recent progress reporting added to `port activate` and `port deactivate`. (Which causes a significant increase in duration of those operations.) 2. a Pextlib function is introduced to determine whether `port` runs as a foreground process connected to a terminal. This function is called to check the current state before doing any actual progressbar output. It thus becomes possible to push a long-running operation (say, a build) to the background and do other work in the same terminal, without getting frequent terminal and most likely illegible output.
RJVB
force-pushed
the
progressbar-tweaks
branch
from
b7bb721
to
7535dcc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Progress reporting is useful but also has its drawbacks, like writing to the calling terminal when it's not in the appropriate state, or slowing down the process being reported on. This commit addresses both situations:
a set of 3 configuration variables is introduced with which the user can control (via macports.conf) after how long the progressbar should appear, if it should also show indeterminate progress (aka "we're busy") and what operations should report progress in addition to the traditional ones (fetch, build, destroot). The defaults for these are the current hardwired settings. The "also_for" setting is designed to be a list that currently only accepts "de/activation" for the recent progress reporting added to
port activateandport deactivate. (Which causes a significant increase in duration of those operations.)NB: I didn't think it necessary to design separate entries for activation and deactivation, but it annoys me a bit that now I have to do the same check in 2 locations.
a Pextlib function is introduced to determine whether
portruns as a foreground process connected to a terminal. This function is called to check the current state before doing any actual progressbar output. It thus becomes possible to push a long-running operation (say, a build) to the background and do other work in the same terminal, without getting frequent terminal and most likely illegible output.