Make the error window size configurable

[samoht]

Would be nice if we can configure the size of error message (using for instance an env variable). Because this is not very helpful:

# ...[truncated]
# OpenMP:         True
# Prefix:         /home/travis/.opam/system
#64-bit:         True
# Python version: 2.7
# Writing build/Makefile
# Copied Z3Py example 'example.py' to 'build'
# Makefile was successfully generated.
#   python packages dir: /home/travis/.opam/system/lib/python2.7/dist-packages
#   compilation mode: Release
# Type 'cd build; make' to build Z3

[dbuenzli]

I don't think it should be configurable (you can always access the log file which IIRC is actually printed with the error). However the default size could be much larger.

[avsm]

Making it configurable would be quite convenient in Travis, especially in the case of multiple errors in a parallel build.

[AltGr]

Ok, can be easily added now. Note that I already tried to make it slightly more clever by printing the latest unindented line on top (à la diff).

[dbuenzli]

Ok, can be easily added now. Note that I already tried to make it slightly more clever by printing the latest unindented line on top (à la diff).

Ha ! When was that introduced ? (still on 1.2.0, such an old fart).

That said I'm wondering if in case of error it wouldn't be more smart to dump all the shit -- followed by a high-level error message, this could maybe avoid a few round trips with repo maintainers when problems occur. Mais pas clair.

[AltGr]

What I'm afraid of is that it may make relevent information above (on what OPAM is doing and why) lost ; starting to get more complicated, but an UI could be:

• store the errors from last run somewhere under ~/.opam
• rather than printing details on log files, etc. just advertise opam errors
• opam errors gathers all meaningful information and prints it out, to diagnose or report.

Just an idea...

[samoht]

store the errors from last run somewhere under ~/.opam

isn't that already the case?
What's the semantics of opam errors if you have multiple concurrent runs?

[AltGr]

It could store more information on the run thant the individual logs we already have if needed, and keep links to the different processes' outputs. opam errors would list them all, and possibly allow you to select the ones you want to see.

[dbuenzli]

I think something like opam errors could be nice, I prefer to have that command rather than have to each time copy and paste the error log path to less it. If I can simply to opam errors | less then it's 1) always the same command line to invoke 2) avoids a trip to the trackpad and the c&p procedure.

But surely there are lot of UI nitty gritty details to solve to make sure you a) know what you are reading b) read what you want to read.

Regarding the multiple failures it seems to me it that you are interested in each of them (unless there may be cascading errors but I think this should not be the case, since opam will not proceed if the dependends of some things errored). So it seems to me that a cat of all the logs with clear markers that allows to quickly jump/grep from one to the other should be sufficient.

[samoht]

opam error would be also useful to run automated analysis tools on the error log files. Currently that's a bit difficult to extract the filenames if needed.

[AltGr]

This is done, opam error should probably be in a separate issue :)