First pass refresh of hab CLI UI with musl/libc fix.
#522
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
|
By analyzing the blame information on this pull request, we identified @reset, @metadave, @adamhjk, @smith and @jtimberman to be potential reviewers |
|
☔ The latest upstream changes (presumably 3473af4) made this pull request unmergeable. Please resolve the merge conflicts. |
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
fnichol
force-pushed
the
fnichol/hab-ui-pass
branch
from
7dbd29f to
e196df4
Compare
| let pair = try!(SigKeyPair::generate_pair_for_origin(origin, cache)); | ||
| println!("Successfully generated origin key {}", pair.name_with_rev()); | ||
| println!("{}", | ||
| Blue.paint(format!("★ Generated origin key pair {}.", |
There was a problem hiding this comment.
we start with Generating origin key and finish with Generated origin key _pair_
|
output looks great! 🍰 🍰 🍰 🍰 🍰 |
|
📌 Commit e196df4 has been approved by |
thesentinels
pushed a commit
that referenced
this pull request
May 17, 2016
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Pull request: #522
Approved by: fnichol
thesentinels
pushed a commit
that referenced
this pull request
May 17, 2016
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca> Pull request: #522 Approved by: fnichol
thesentinels
pushed a commit
that referenced
this pull request
May 17, 2016
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca> Pull request: #522 Approved by: fnichol
|
@metadave Agreed on some of the wording. It's not 100% yet (especially the conclusion/summary lines) but is something we can start to tighten the screws on.
|
|
☀️ Test successful - travis |
jtimberman
pushed a commit
that referenced
this pull request
Jun 12, 2016
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Pull request: #522
Approved by: fnichol
jtimberman
pushed a commit
that referenced
this pull request
Jun 12, 2016
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca> Pull request: #522 Approved by: fnichol
jtimberman
pushed a commit
that referenced
this pull request
Jun 12, 2016
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca> Pull request: #522 Approved by: fnichol
raskchanky
pushed a commit
that referenced
this pull request
Apr 16, 2019
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Pull request: #522
Approved by: fnichol
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.
hab CLI
This change is part spike and experiment and part functional. It is a first attempt at unifying the
habCLI output and formatting to be more consistent and easier to scan as a newcomer (in the short term) and experienced user (in the long term).Most of the commands have the following narrative, much like an essay:
Here is an example of a package install invocation:
musl/libc/ioctl
In the course of building in a progress bar, an issue was found with in the
libccrate relating to the types of ioctl contants when used by musl (more detail in: rust-lang/libc#289). Unfortunately, this meant vendoring libc so that it would be used as a transitive dependency in the crates that generated the errors (currently this is thepbrcrate, which is completely correct in its implementation). Without this temporary measure, thehabCLI won't build as-is with the musl target. The other option is to feature-disable the progress bar until the upstream is resolved, but it really hampers the far superior user experience that a progress bar like this provides.