Obey environment variable(s) or dot-file for disable/enable and options

[jtara]

It would be handy if xcpretty would obey some environment variables and/or (MY preference) a dot-file (e.g. .xcpretty) giving the ability to disable or to provide overriding options.

As I understand it, currently it takes only command-line parameters. This puts the burden on any build process running xcpretty to provide a way of changing options.

I think the need here is somewhat the reverse of the norm - e.g. normally, some dot-file and/or environment variables are the starting point, and then command-line parameters override.

I would like a way to at least disable from a dot-file or environment variable. Options would be good too, but the main thing for me is disable.

Maybe some thought needs to be given to appropriate key names and/or filename.

Here is my specific use case: I use Rhomobile Rhodes:

https://github.com/rhomobile/rhodes

Which has a big build process, and optionally supports xcpretty. If xcpretty is installed, it will use it, otherwise it does not.

Sometimes, though, I really want to see everything. My workaround right now is to either uninstall xcpretty (ugh!) then re-install it later, or keep separate Gemsets in rvm. (ugh as well).

I've put in a complementary Issue with the Rhodes project. I'll be happy with either (or both) solutions!

rhomobile/rhodes#499

But I'm not sure that "fixing" Rhodes is really the right way, as I would think it a common scenario. Every build process that uses xcpretty should not have to build-in support for disabling it.

Or, if I am missing something that already exists, perhaps add it to the documentation?

[supermarin]

Short answer: you're doing it wrong 😄

Long answer:
xcpretty has only a few essential flags, and if there's a need to have too many of them, probably we need to change the default configuration.

Storing the raw xcodebuild output is always a good thing to have;
I recommend using the UNIX tool tee for writing to a file, and then piping to xcpretty for a readable output.

Take a look at this example:

$ xcodebuild test | tee xcodebuild.log | xcpretty -c
   ^                         ^           ^
   run build                 |           what you see in console
                             |
           save the raw output to a file called `xcodebuild.log`

[jtara]

I'm not doing it wrong. I don't have a choice in the matter. Unless I want to fork the Rhodes project.

They just run Xcode output through xcpretty, without giving the user (developer) a choice.

Sure, they ought to do as you suggest, and I've put in an Issue with that project, as well.

But, realize - they won't be the first project to use xcpretty in this manner.

So, it would be nice to have some way to bail out and bypass it with some environment variable, etc.

So, I am left only with the kludge of having to un-install the xcpretty Gem every time I want to see full Xcode build details. Or, having two Gemsets, one with XCPretty installed, and one without.

Rhodes check to see if xcpretty is available. If it is, it uses it. If not, not.

[supermarin]

@jtara please don't take the upper one as an insult, I've tried to be funny.

That's too bad - I'm not familiar with their build framework; maybe it'd be a good idea for you to submit a pull-request to them, with xcodebuild.log support.

There was a plenty of requests for adding stuff like this, exiting with other status codes,..
But xcpretty is just a formatter and I'd prefer to keep it simple.

[jtara]

Hmmmm.... I see what you mean now.

Console output should be concise. If you want to see the full details, then examine the voluminous output in a saved file. Better than scrolling back through thousands of lines of console output.

In any case, it's a useful thing to save the build log to a file anyway.

I'll see about just doing a pull request against Rhodes. This is only in their master branch right now, which isn't due for release until 3Q15. So, plenty of time before actual release. I did look at the change-set for it, and I recall it was pretty small anyway.

I've occasionally teed the output to a file myself, but of course once it has run through xcpretty, it is too late to get the details. It has to be done in their build process. They will probably want an option added in their build config file to toggle tee/don't tee.

So, that kills two birds anyway.

[supermarin]

You can also make a hack in the meantime, until your PR gets in:

$ xcp=$(which xcpretty)
$ alias xcpretty=tee
$ run-your-rhodes-build | tee xcodebuild.log | $xcp -c

I haven't tried this (just wrote by heart) but it'll probably work, unless rhodes is spawning a new shell instance. In that case you want to export the alias globally

[jtara]

Oh. Thanks.

That actually won't work for their master branch, because they already pipe through xcpretty internally if it is present. That's the whole problem I have - they provide no way to defeat it!

But... I am not using the master branch anyway. The one I use day to day doesn't even have xcpretty.

So, duh, I can just tee and pipe the output myself.

However.... the output is more than just Xcode build. There is a lot of stuff before they get to Xcode build, and I don't know how happy xcpretty will be with that....

I'll give it a try, though, and also do a fork of their master and see if I can provide a tee functionality, which is useful in any case.

This is what they did. I'll have to look into just what they are doing here when I have a chance.

rhomobile/rhodes@e9ab634

They use XCPretty::Printer

Oh, so I can just also output to a file in both of those loops. Easy. There ought to be an option to turn that off I guess.