Add ability to cache command line arguments

[t00sa]

This adds a feature which allows complex command line arguments to be written to a cache file and then re-used. Where an argument is specified in both the cache and on the current command line, the command line version takes priority.

Cache arguments themselves are not sticky, so if --save-cache and --use-cache are set on the command line, they will get written to the cache but ignored when the cache is next loaded. This prevents the cache from being inadvertently overwritten with new arguments.

[t00sa]

It looks like the CI problems may be a consequence of the earlier versions of python - and pyfakefs? - because the 3.11 tests have run through cleanly.

I've converted the PR into draft while I try to narrow down the problem.

[t00sa]

I was able to duplicate the problem interactively with python 3.9. Replacing the pyfakefs fixtures with pytest tmp_path has resolved the problem. Marking the PR as ready to go.

[t00sa]

This should probably go on after #476. It's going to conflict, so I'll need to update the branch once the other change is on.

[hiker]

This new feature should also be added to the Fab basceclass, so the user experience across the various CLI is consistent.

So, it should go in after #414 (which after all is the only high priority item and a release blocker, ready to be reviewed and as such must have priority).

[t00sa]

@hiker, that's a good suggestion. Now that the FabBase change has been merged, I've updated my branch, refactored the caching mixin slightly, and created a CachingArgumentParser class which extends the standard argparse.ArgumentParser class.

I've added this as a drop-in replacement for the parser in FabBase and added some tests which confirm the basic functionality. I'm interested in your opinion. All the work that touches FabBase is contained in commit cadabb0 so it can easily be removed from the PR if you don't think it is a good idea.

[hiker]

@hiker, that's a good suggestion. Now that the FabBase change has been merged, I've updated my branch, refactored the caching mixin slightly, and created a CachingArgumentParser class which extends the standard argparse.ArgumentParser class.

I've added this as a drop-in replacement for the parser in FabBase and added some tests which confirm the basic functionality. I'm interested in your opinion. All the work that touches FabBase is contained in commit cadabb0 so it can easily be removed from the PR if you don't think it is a good idea.

Looks nearly perfect to me: the only suggestion I have is to keep the type declaration to be argparse.ArgumentParser (since CachingArgumentParser is derived from this anyway). Reason for this is that a script derived from FabBase could provide its own version of an argument parser to FabBase, e.g. to provide a better description instead of the default one set in FabBase (not sure if the description can (officially, i.e. without accessing some undocumented features) be changed. Plus a user might want to do other customisations??). We should of course document that your class is recommended to be used even in this case, but as far as I can see there is no need to restrict/enforce this, and who knows what a user might decide to do. If your class adds new features that changes the API (and is used in FabBase, then of course it must be declared as CachingArgumentParser). But as far as I can see, atm the API is still the unchanged. Thanks!

[t00sa]

Thanks @hiker, I'm glad you think this is useful. I'm going to pick this up again shortly, integrate your suggestions, and get the PR moving again.