Add decorator to brew info $pkg dependency list to indicate Dependency#installed?

[colindean]

• Replace simple join output with decorator method.
• Define default decorator method.
• The default decorator method shows green check if installed or red X if not.

Using a decorator method here enables a user to override Homebrew#decorate_dependencies with whatever they desire. I like the green checkmark and red X, so I offer them for the default. An simpler, less unicode-y alternative would be to simply highlight the dependency package name in the given color.

My personal motivation here is to use the indication as a factor in determining if I want to install a package right now. If I look at a package's info and see that none of its dependencies are installed, and installing them may take a while, I may reconsider installing that package right now if I'm on battery or if I'm doing something that CPU or disk usage from compiling may negatively affect.

Future work would include a similar decorator for conflicting packages, displaying some kind of a warning character if a conflicting package is installed.

[SevenBits]

Sounds cool.

[cooljeanius]

An simpler, less unicode-y alternative would be to simply highlight the dependency package name in the given color.

This could be the automatically selected option when the HOMEBREW_NO_EMOJI environment variable is set.

[jacknagel]

Please, let's avoid the proliferation of unicode output, optional or otherwise.

[adamv]

Create an external command that does this

[SevenBits]

Why, exactly? I'm pretty sure Terminal has Unicode support. I doubt it really matters anyway. Pretty much everything nowadays had Unicode support.

On Apr 3, 2013, at 12:57 AM, Jack Nagel [email protected] wrote:

Please, let's avoid the proliferation of unicode output, optional or otherwise.

—
Reply to this email directly or view it on GitHub.

[jacknagel]

Why, exactly? I'm pretty sure Terminal has Unicode support. I doubt it really matters anyway. Pretty much everything nowadays had Unicode support.

On what versions of OS X? (This is rhetorical). Please look through the threads about the beer emoji. Stuff like this has disproportionate maintenance costs.

If this is really necessary, the deps should just be colored differently, but I'm ambivalent about even that. Someone should just make a brew installed-deps <formula> command.

[MikeMcQuaid]

Given we have the environment variable and to hide unicode and show it otherwise on every brew install I'm actually up for using more unicode where it displays more information in a single character. Whether it does in this case or not I'm not sure.

[colindean]

So, direction. I need it.

Suggestions:

• As-is.
• Display single character normally, but only highlight dependency when HOMEBREW_NO_EMOJI is set.
• Only ever highlight dependency
• Revert this, and create a separate command that checks dep install status

I'd like to do this:

1. if HOMEBREW_NO_EMOJI highlight dependency, else display single unicode character normally
2. Create deps command that outputs a list of dependencies, potentially in some kind of tree

I feel that № 1 is within scope of this PR. № 2 is a useful idea show dependencies and their status, with an eventuality to resolve the dependency tree, if such a command doesn't already exist.

Ultimately, I'll do whatever you all think is appropriate for the project.

[MikeMcQuaid]

I think probably a separate (external) command for now perhaps makes more sense. Open to other ideas from other maintainers though.

[mxcl]

I like it. And think it's very useful. Why you against it @jacknagel?

It would be necessary to detect non-tty and output with plainer text though I should think.

[jacknagel]

I've stopped caring and checked out of this thread because nobody seems to care that Homebrew is going to look like a cartoon soon. Do whatever.

[cooljeanius]

nobody seems to care that Homebrew is going to look like a cartoon soon.

I care. That's why I brought up the HOMEBREW_NO_EMOJI environment variable in the first place.

[SevenBits]

Who cares, really? Programs evolve based on the wishes of their users. If you don't like where Homebrew is going, use another tool.

On Apr 6, 2013, at 1:57 PM, Jack Nagel [email protected] wrote:

I've stopped caring and checked out of this thread because nobody seems to care that Homebrew is going to look like a cartoon soon. Do whatever.

—
Reply to this email directly or view it on GitHub.

[adamv]

Please do this as an external command so we can test drive it before we decide whether or not to put it into core.

[adamv]

For the record, I'm -1. I'd like to see a core set of brew commands that do simple machine readable output, sort of like the porcelain levels of Git, and a set of command on top, or separate UI packages on top, that do the "angry clown salad" thing (think tig).

[MikeMcQuaid]

It remains machine readable as-is; just relies on unicode characters. I think it's actually a good call in cases like this where a single unicode character communicates more than any non-unicode one does.

[SevenBits]

I agree.

On Apr 7, 2013, at 5:50 PM, Mike McQuaid [email protected] wrote:

It remains machine readable as-is; just relies on unicode characters. I think it's actually a good call in cases like this where a single unicode character communicates more than any non-unicode one does.

—
Reply to this email directly or view it on GitHub.

[colindean]

I've taken action to respect HOMEBREW_NO_EMOJI when set.

@MikeMcQuaid: It remains machine readable as-is; just relies on unicode characters. I think it's actually a good call in cases like this where a single unicode character communicates more than any non-unicode one does.

This is my primary motivation for using a single unicode character. It seems that it would already be wise for a machine-reading program to set HOMEBREW_NO_EMOJI anyway.

I will endeavor to submit in a separate pull request a new command deps that shows the dependencies alone.

[SevenBits]

I'm glad Unicode characters are being used. This was a good decision.

On Apr 7, 2013, at 6:38 PM, Colin Dean [email protected] wrote:

I've taken action to respect HOMEBREW_NO_EMOJI when set.

@MikeMcQuaid: It remains machine readable as-is; just relies on unicode characters. I think it's actually a good call in cases like this where a single unicode character communicates more than any non-unicode one does.

This is my primary motivation for using a single unicode character. It seems that it would already be wise for a machine-reading program to set HOMEBREW_NO_EMOJI anyway.

I will endeavor to submit in a separate pull request a new command deps that shows the dependencies alone.

—
Reply to this email directly or view it on GitHub.

[chdiza]

Somehow with colors and dingbats the output of brew info is even harder to read than it already is.

It is already hard to read (prior to this proposal) because the list of deps is a comma-separated list and isn't columnized. The part under "Depends on:", whether colorized or dingbatized or not, should be like the output of brew list.

Also, it isn't true in this case that a single unicode character is conveying more than any non-unicode one. E.g., what's wrong with good ol' Y and N rather than the corresponding unicode dingbats?

[SevenBits]

@chdiza The "dingbats" stand out and give a bit of visual appeal.

[colindean]

Any additional thoughts or direction on this?

[MikeMcQuaid]

I'll have a look.

[MikeMcQuaid]

What does xout mean?

[colindean]

It means cross out or just X. I didn't want to use a single letter variable that seemed more likely to evoke this very same question.

[MikeMcQuaid]

Maybe name them tick and cross?

[colindean]

I'm not sure that those are any more indicative of their use or content, since it's difficult to determine what character is assembled by the code there. I'd considered using yes and no, but then it'd be just as difficult to determine the character.

Maybe remove the coloring from there and rename xout to crossout. I think of ✝ when I think of cross. Then, have another variable set that adds the color to the characters. This makes it a little easier to read. Or, pulling those into a function would allow easier overriding for custom settings.

[MikeMcQuaid]

cross_out sounds good.

[colindean]

I'll update it here and on my other PR.

[MikeMcQuaid]

This works for me but I'll wait for a +1 from another maintainer.

[colindean]

Changed xout to cross_out per @MikeMcQuaid's suggestion.

[adamv]

I'm now -0 on this since I can turn it off with the EMOJI env var.

If @MikeMcQuaid is still OK with this, this needs to be rebased on master for review.

[colindean]

Interestingly enough, I'm planning to work on that rebase tonight...

[MikeMcQuaid]

Cool. Let's rebase and I'll get on it.

[colindean]

Rebased. Interestingly enough, I found a bug caused by this comment's additions and fixed it, too.

[colindean]

@MikeMcQuaid Any other feedback? I'd like to get this in before I have to do another big rebase ;-)

[MikeMcQuaid]

@colindean Will review properly ASAP.

[MikeMcQuaid]

Pushed. Thanks @colindean.

[colindean]

Thanks, folks!

[jjbohn]

I've started getting an error from this:
Error: undefined method '+' for nil:NilClass

Trace:

/opt/boxen/homebrew/Library/Homebrew/cmd/info.rb:141:in `decorate_dependencies'
/opt/boxen/homebrew/Library/Homebrew/cmd/info.rb:125:in `info_formula'
/opt/boxen/homebrew/Library/Homebrew/cmd/info.rb:123:in `map'
/opt/boxen/homebrew/Library/Homebrew/cmd/info.rb:123:in `info_formula'
/opt/boxen/homebrew/Library/Homebrew/cmd/info.rb:36:in `print_info'
/opt/boxen/homebrew/Library/Homebrew/cmd/info.rb:34:in `each'
/opt/boxen/homebrew/Library/Homebrew/cmd/info.rb:34:in `print_info'
/opt/boxen/homebrew/Library/Homebrew/cmd/info.rb:17:in `info'
/opt/boxen/homebrew/Library/brew.rb:91:in `send'
/opt/boxen/homebrew/Library/brew.rb:91

[cheister]

I think this PR #24188 should fix the undefined method error