Pretty error reporting

[angelcerveraroldan]

The goal of this PR is to add pretty error reporting, since the difference is visual, I have attached screenshots for the errors that butane would report for the following butane:

variant: fcos
version: 1.6.0
boot_device:
  layout: s390x-virt
  mirror:
    devices:
      - /dev/vda
      - /dev/vdb
systemd:
  units:
    - name: example.service
      enabled: true
      contents: |
        [Unit]
        Description=Example
      contents_local: example.service
    - name: other.service
      dropinz:
        - name: override.conf
          contents: |
            [Service]
            ExecStart=
    - name: valid.service
      enabled: true

How errors show without this feature:

How errors show with the new feature:

New flags added:

1. --pretty-errors to turn on pretty error reporting
2. --color[=WHEN], where WHEN is auto (default), always, or never. This follows the same convention as ls, ripgrep, diff, bat, exa, ... In auto mode, colors are disabled if stderr is not a terminal or if the NO_COLOR environment variable is set. It also accepts colour just in case

This is an early PR to get feedback on whether or not this is a good addition to butane, or if it should go somewhere else / nowhere. I am not sure if the current flag name pretty-errors is good or not, seems kind of verbose to me.

[gemini-code-assist]

Code Review

This pull request introduces a new reporting package to provide enhanced, "pretty" error messages with source code context and ANSI colorization. The main entry point is updated to track input filenames and utilize these formatting options. Key feedback points include resolving a package name conflict that prevents compilation, implementing bounds checking for string slicing to avoid runtime panics, dynamically managing colorization for non-TTY outputs, and ensuring error underlines remain visible when pointing to whitespace.

[travier]

This looks great to me. +1 from me. Untested.

[travier]

--pretty-errors to turn on pretty error reporting

Should we have this on by default? Butane output should be for humans so good default for humans sounds like a good idea.

[angelcerveraroldan]

--pretty-errors to turn on pretty error reporting

Should we have this on by default? Butane output should be for humans so good default for humans sounds like a > good idea.

I did not enable it by default in case the raw output was being used in any automatic things. But if its meant for humans only, then having it by default may be nice, as otherwise a lot of people may not know it is available. Open to going either way.

[prestist]

hmm, I think opt in makes sesne, but having the many different flags can lead to a little confusion. separate flags imply they do something separately, i.e --color without --pretty-errors does not really do anything right?

Is there a way we can make --color a sub-option of --pretty-errors?

[angelcerveraroldan]

The reason I had setup color with those flags is to follow the standard convention that most programs use.

I do think that having colors only be used for pretty errors can be strange, specially so if pretty errors is opt-in rather than opt-out. I am not entirely sure how to make colors a sub option of pretty errors nicely.

Maybe something like: --pretty-errors=color, --pretty-errors=no-color, as well as --pretty-errors=auto, where auto checks if its a tty or not / if NO_COLOR is set. (If --pretty-errors is not set then use the normal errors)

I am not sure if this is less confusing or not.

[travier]

I would default to the new pretty output and add another option (--json ?) to output machine readable output instead.