update code to also support PrettyTables v3

[disberd]

This PR update the code (and Project compat) to support version 3 of PrettyTables

Since version 3 brings breaking changes in the API of pretty tables, I decided to go with the branching solution based on the PrettyTables version rather than dropping compat to earlier versions.

I tested locally with v2 and tests still pass, don't know if one of the maintainers would want to add a CI test also testing with PrettyTables v2.

I think this update is needed for use of LocalCoverage in CI as this usually involves adding LocalCoverage to the global environment and then using it directly in a process where the current environment is the package under test.

In this scenario, despite LocalCoverage having a compat to v2, the v3 of PrettyTables is being loaded if that is a dependency of the package under test, leading to error at runtime when trying to generate the coverage.

[tpapp]

Thanks for the PR. As far as I am concerned we can just drop the previous version of PrettyTables and require the latest one, and not branch in the code.

[disberd]

Thanks for the fast reply @tpapp. I think the branching might still be useful for the reverse problem of what I was facing in CI.

If someones loads the new version of LocalCoverage only compatible with v3 of PrettyTables in the global env, but then has the test env which still depends on v2 of PrettyTables (migration is not always straighforward and I understand a bunch of packages are still locking to v2 of PrettyTables), the LocalCoverage code will still throw an error as it will try to use TextHighlighter which does not exist in the v2 of PrettyTables (loaded because the package under test in its environment does not allow v3 of PrettyTables).

This is still a easier problem to solve than currently (as it's sufficient to pin the LocalCoverage version in the global env when adding it prior to testing in CI), so if you still prefers to avoid branching I'll just update the PR accordingly

[tpapp]

This is a valid argument for the branches. So let's keep them; I will review in detail soon.

[disberd]

Thanks @tpapp, meanwhile I am also linking two PRs to PrettyTables with some docs inconsistencies I found while working on this PR:

• add kwarg constructor as documented ronisbr/PrettyTables.jl#273
• make 0 autosize column width as documented ronisbr/PrettyTables.jl#274

[disberd]

@tpapp did you have a chance to have a look at this?

[burtonjosh]

Thanks @disberd for this PR and @tpapp for taking the time to look. This issue is also affecting me, is there anything I can do here to help get this merged?

[tpapp]

My understanding was that we were waiting for @disperd's PRs to get merged, which I think happened, so that code could be simplified. Once that happens I will merge instantly, this is a very useful PR.

[disberd]

Ah ok @tpapp I never got any feedback that you were waiting for modifications after the PR so I was also just waiting on some feedback :D

[tpapp]

@disberd I apologize, my bad, I forgot to follow up.

[disberd]

@tpapp I did update the code after the PR were merged (with very minor simplification), update the compat of PrettyTables v3 so that it ensures the merged PR are there.

CI was succesfull before my last commit which was just merging the commits to master since this PR was opened, so it's a bit unclear why CI seems to fail in the latest merge commit.

Additionally, it would be good to have a test also with PrettyTables v2 but I know it's not so trivial to test with different versions of dependencies...

[tpapp]

@disberd, thanks for the update, and your patience. I will merge now and release a new version.

[tpapp]

@disberd: I don't have time to set up a test framework for PrettyTables v2 now, but PRs are welcome. But, TBH, I would just rely on bug reports and fixing it if it fails.