Some fixes to the way click-man interfaces with click

[ferdnyc]

This PR corrects some issues I ran into trying to run click-man on Black's command-line tool black, using the latest development version of Click.

1. Click can have a version string like "8.0.dev" which breaks the attempted numeric parsing. Switch to using distutils.version.LooseVersion() for version comparisons, instead.
2. The click.Context has to be passed in to get_help_record(), or it can sometimes throw an exception.
3. A tool's entry point isn't always its click.Command object.

The last item is the really ugly one: black has as its entry point black:patched_main, which as the name implies does some monkeypatching of its environment before finally calling its actual black:main, which is the click.Command object for the module.

Since isinstance(black.patched_main, click.Command) is False, trying to turn it into a click.Context() breaks.

But with a bit of work, and help from importlib and inspect, we can search the entry_point.module_name module for a click.Command object, wherever it may be hiding.

Note that this may still break, or do the wrong thing, if a tool's entry_point isn't a click.Command object and it has multiple click.Command objects in its module. But hopefully that combination is an exceedingly rare case.

[ferdnyc]

Any chance someone (@timofurrer ?) with access could restart the Travis builds for this PR?

The failures were only due to outdated Python 3.3 and 3.4 runs, which were fixed by the merge of my PR #36. And I'd like to get these changes incorporated upstream, if at all possible, since we'd like to use click-man to build a manpage for the Fedora Black package.

[timofurrer]

Thanks for the enhancement and sorry for the delay!

I'll release to PyPI asap.

[ferdnyc]

Thanks @timofurrer!

I wrote:

Note that this may still break, or do the wrong thing, if a tool's entry_point isn't a click.Command object and it has multiple click.Command objects in its module. But hopefully that combination is an exceedingly rare case.

For the record, I thought of one additional way this could break — if the click.Command object is in a completely different module than the entry_point, even with my changes the code will fail to properly discover and document the command-line structure. (Which is no different than without my patch, so at least there's no regression.)

...Anyway, hopefully that kind of craziness is even more rare than the previous scenario.

[timofurrer]

Okay, once I'll have some more time again - I can have a closer look into it.

For now, I've just released to pypi :tada:

[ferdnyc]

Great, thanks! I'll ask the Fedora packager to roll an update, once that's available the Black packager can incorporate it into their RPM spec.

...Actually, sorry, just one quick question: The PyPi files listing for 0.4.0 shows the Source package as being named click-man-0.4.0.linux-x86_64.tar.gz instead of just click-man-0.4.0.tar.gz.

Which differs from the click-man-0.3.0.tar.gz format used for click-man 0.3.0 and previous releases.

Is there a reason for that change? Because, the source URL generated by the click-man RPM spec, https://files.pythonhosted.org/packages/source/c/click-man/click-man-0.4.0.tar.gz, now results in a 404.