Closed ferdnyc closed 4 years ago
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.
Thanks for the enhancement and sorry for the delay!
I'll release to PyPI asap.
Thanks @timofurrer!
I wrote:
Note that this may still break, or do the wrong thing, if a tool's
entry_point
isn't aclick.Command
object and it has multipleclick.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.
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:
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.
This PR corrects some issues I ran into trying to run
click-man
on Black's command-line toolblack
, using the latest development version of Click."8.0.dev"
which breaks the attempted numeric parsing. Switch to usingdistutils.version.LooseVersion()
for version comparisons, instead.click.Context
has to be passed in toget_help_record()
, or it can sometimes throw an exception.click.Command
object.The last item is the really ugly one:
black
has as its entry pointblack:patched_main
, which as the name implies does some monkeypatching of its environment before finally calling its actualblack:main
, which is theclick.Command
object for the module.Since
isinstance(black.patched_main, click.Command)
isFalse
, trying to turn it into aclick.Context()
breaks.But with a bit of work, and help from
importlib
andinspect
, we can search theentry_point.module_name
module for aclick.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 aclick.Command
object and it has multipleclick.Command
objects in its module. But hopefully that combination is an exceedingly rare case.