Validate on all pod commands that the user is using a terminal in utf-8

[joshkalpin]

When finished this should fix #1542. I'm not sure if this is the best way to handle this and what to do with the 1.8.7 case but I think it's a start at least.

[coveralls]

Coverage remained the same when pulling c9e08db on Kapin:utf-8-validation into 525180c on CocoaPods:master.

[coveralls]

Coverage remained the same when pulling 0cfcf4c on Kapin:utf-8-validation into 525180c on CocoaPods:master.

[fabiopelosin]

Great!

Some questions:

• Why did you remove the parenthesis from the if statement? CocoaPods always use them.
• Should we raise or just print a message in yellow? Not sure about this, just proposing the alternative.
• I think that we should introduce a little explanation about hot to fix the issue. We could either indicate how to set up the environment directly or link to a relevant resource (for now just an issue, in future maybe a troubleshooting section guides.cocoapods.org).

[joshkalpin]

1. Removed parenthesis because I was't thinking. I'll restore them.
2. Raising seems to explode the builder at this point (might be a travis config issue?), but besides that I think that if a user can't use CocoaPods properly without it, I would say it is an error.
3. The copy was temporary. I'd definitely rather do that :)

[alloy]

Why did you remove the parenthesis from the if statement? CocoaPods always use them.

Is that since the introduction of the new style tool? Although a quick look through the sources does not seem to indicate they are being used in any if statement.

[fabiopelosin]

@alloy Actually you're right. I prefer to use the parenthesis though when there is more than one condition tested (i.e. a logic operator is used like &&)

[fabiopelosin]

Btw, @kapin don't forget about the changelog 😄

[joshkalpin]

@irrationalfab of course. Could you help me look into why travis is breaking? It appears that one of the builders is not using utf-8 encoding :)

[fabiopelosin]

@kapin ah, it looks like your deduction is correct. You could further investigate it with a test commit :-/ it by printing the value of Encoding.default_external. This is one of the reasons why I'm tempted not to raise. CocoaPods works fine in the 99% even without that setting. The issue manifests itself only with certain Pods.

[joshkalpin]

@irrationalfab, fair enough on that point. I'll convert it to a warning.

[fabiopelosin]

👍

[joshkalpin]

Wasn't sure the best way of doing the yellow so I improvised. I know we do it elsewhere but I didn't want to start pulling in dependencies all over the place. Once again copy is up for debate but it is better than last time.

[coveralls]

Coverage remained the same when pulling 5105f98 on Kapin:utf-8-validation into aa25ac0 on CocoaPods:master.

[fabiopelosin]

@kapin In this specific case, as it would not be appropriate to import dependencies, as you say, I use a solution similar to yours. However instead of monkey patching the string class (with the same method that later on will be overridden by the colored gem) I would prefer to simply wrap the two strings with the color codes inline. I.e.

puts "\e[33mWARNING: blah blah.\e[0m"

[coveralls]

Coverage remained the same when pulling ad7630d on Kapin:utf-8-validation into aa25ac0 on CocoaPods:master.

[fabiopelosin]

Aceness looks great to me!

[joshkalpin]

@irrationalfab merge as is or would you prefer I squash?

[fabiopelosin]

As a general rule we prioritize getting things done on keeping a clean history. However in this case I think that a nice squash would be sweet.

[joshkalpin]

@irrationalfab closing this and going to open a squashed one and merge it.

[fabiopelosin]

@kapin Actually I was wrong :-/ the recommendation, which sounds reasonable to me, from the Ruby Style Guide is:

Don't use parentheses around the condition of an if/unless/while/until.