Remove space before colon in livecheck output

[triallax]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally? (There are some failures but they seem unrelated)

---

I find the space before the colon mildly irritating and saw no reason to keep it, but if there is one feel free to close this PR.

[Lillithlilly]

Approve

[nandahkrishna]

I've been mildly annoyed by the space before the colon in the past, although I've mostly just chosen to ignore it. I can't immediately think of any drawbacks – I don't think it makes pattern matching any harder, and we have --json anyway for something that can be easily processed by programs. I wonder if anyone else (maybe @samford) feels strongly against this change.

[Bo98]

We make absolutely no guarantees elsewhere about the "stability" for output parsing outside of --json so I'm fine with this from that standpoint. Anyone parsing output should absolutely be using --json.

[Lillithlilly]

Looks good

[samford]

Honestly, I would be surprised if anyone who uses livecheck is fond of the space before the colon 😆. I think most people have simply accepted it as something that has been around since the beginning (late 2014).

I overhauled a lot of livecheck's output in 2020 but I didn't change the colon spacing because, at the time, there was a project going on that was parsing the default livecheck output (i.e., the beginnings of brew bump) and I couldn't justify breaking that for a minor aesthetic change. That code has since been reworked to use livecheck's methods, so that's no longer a concern. At this point, anyone who wants to work with livecheck's data in a programmatic fashion should use the --json flag (or --json --verbose if they want additional metadata).

I don't see it as an issue if this breaks third-party parsing of default livecheck output, as we haven't made any guarantees about the output format and it would arguably serve as an opportunity for them to migrate to parsing the JSON data instead. I can at least say that this shouldn't affect Homebrew, as we either parse JSON output (working from the outside) or directly use livecheck's methods (working from the inside).

Long story short, I'm fine with this general idea.

[MikeMcQuaid]

Thanks so much for your first contribution! Without people like you submitting PRs we couldn't run this project. You rock, @mhmdanas!