Improve catalog update process and script, including tests

[edwardchalstrey1]

Issues closed by this PR

• Closes Simplify how Makefile.am is updated in catalog update script #888
• Closes [Catalog]: Add a DrawTree settings config #885
• Closes [Catalog]: Use curated EF files for catalog visuals by default #886
• Closes [Catalog]: Allow multiple images of the same game #887

Description of the changes in this PR

• This PR has several updates to the catalog update process, both in terms of docs and code, see the linked issues above.
• Also updates the catalog module to ensure that non EFG/NFG files are not picked up by mistake - something @rahulsavani noticed
• Adds help to the update script so you can do python build_support/catalog/update.py --help
• Adds tests for build_support/catalog/update.py covering the functions handling DrawTree settings, updating the variables passed to the Makefile.am and correctly generating the catalog RST doc
• Also updates DrawTree to 0.9.1 which includes fixes to EF->EFG generation

How to review this PR

• Review the developer docs page on how to update the catalog: https://gambitproject--889.org.readthedocs.build/en/889/developer.catalog.html
• And the catalog page itself: https://gambitproject--889.org.readthedocs.build/en/889/catalog.html

[tturocy]

You don't need to have an editable install, but it can be a useful technique if you are working only with the catalog. This needs to be written a bit more carefully though because an editable install doesn't work in general if one is making changes to the C++ part of the code.

This edit might be more confusing than helpful to a less-experienced dev.

[edwardchalstrey1]

Fair enough, I can just make that explicit here - the idea is yes in general developer install would not be editable, but when you're making catalog edits this will definitely save a lot of time

[edwardchalstrey1]

@rahulsavani If you have any EF layout variants for the vonstengel2022 or vonstengelforges2008 games we can include them in this PR since there is now the option for custom EF layouts and to include multiple for a given game.

[edwardchalstrey1]

@rahulsavani If you have any EF layout variants for the vonstengel2022 or vonstengelforges2008 games we can include them in this PR since there is now the option for custom EF layouts and to include multiple for a given game.

Example of how this looks adding 2 EFs for one game when I tested it locally:

[rahulsavani]

@rahulsavani If you have any EF layout variants for the vonstengel2022 or vonstengelforges2008 games we can include them in this PR since there is now the option for custom EF layouts and to include multiple for a given game.

Example of how this looks adding 2 EFs for one game when I tested it locally:

This looks great. I am reviewing the PR now.

One immediate comment: The long list of files does not look great -- can we hide it (within the entry) by default and expand it similarly to the whole entry?

[edwardchalstrey1]

The long list of files does not look great -- can we hide it (within the entry) by default and expand in similarly to the whole entry?

Good idea, have changed that for all the entries and it looks better

[rahulsavani]

I really like the tabs for alternatives.

However, at the moment, to get two or more alternatives one needs to add two or more .ef files to the catalog.

I think a typical use case is that one provides one alternative with the other desired one is that created bydraw_tree (i.e. what we used to have before allowing custom .efs at all).

Currently if one provides a {slug}__{label}.ef without a {slug}.ef the former is ignored and one just gets the default draw_tree one. I think in this case the default and the variant should be created.

[edwardchalstrey1]

Currently if one provides a {slug}__{label}.ef without a {slug}.ef the former is ignored and one just gets the default draw_tree one. I think in this case the default and the variant should be created.

@rahulsavani Just pushed an updated and that is now the case

[edwardchalstrey1]

Just also added a small change to the recently added gilboa1997/fig1 to prevent the action label overlapping the information set boundary:

In draw_tree_settings.yml:

gilboa1997/fig1:
    action_label_dist: 5.0

[rahulsavani]

Thanks, this works nicely. I am happy with this for now.

I added two alternative .efs for vonstengelforges2008; they need some minor tweaks, but I will do that later -- let's get this merged in so you can merge in the bibtex stuff.