[PATCH 1 of 4] extensions: obtain docs by importing modules instead of parsing them
Dan Villiom Podlaski Christiansen
danchr at gmail.com
Fri Jul 31 05:24:12 CDT 2009
On 31/07/2009, at 11.37, Martin Geisler wrote:
> Dan Villiom Podlaski Christiansen <danchr at gmail.com> writes:
>
>> On 31/07/2009, at 08.06, Cédric Duval wrote:
>>
>>> # HG changeset patch
>>> # User Cédric Duval <cedricduval at free.fr>
>>> # Date 1248811268 -7200
>>> # Node ID be5a81430dd6903ac1497315cc49e0456d568a12
>>> # Parent 25255ce87bcfb753df078b2f8cabc6bcb5cb96ce
>>> extensions: obtain docs by importing modules instead of parsing them
>>
>> Are you certain that this is safe? I wrote up a small sed script to
>> remove documentation, and from what I can tell some of the extensions
>> actually modify Mercurial at load. Third party extensions are likely
>> to do it too; so far, extension authors have been able to rely on
>> their modules not being loaded unless the exception itself is loaded
>> and enabled.
>
> The idea is, that this should be equivalent to simply enabling all
> extensions. When you ask for help about an enabled extension, we
> already
> simply return mod.__doc__.
>
> We won't load random third-party extensions, it is only extensions
> from
> hgext that are loaded temporarily by the disabled() function in
> order to
> generate 'hg help extensions'.
Well, I can understand how that's useful: you get the full
documentation, commands and all, for disabled extensions. It's even
100% consistent with the documentation when the extension is enabled.
I can think of a few downsides, though:
1) It won't work for modules with dependancies not present in the
system.
2) Such extensions won't be able to tell users what to install.
3) Won't this make listing disabled extensions a good deal slower?
4) Any alternate single-process clients might have a serious issue
with this.
Are third party extensions still intended to be installed outside
‘hgext’? I can imagine some users, packagers or administrators might
want have all installed extensions listed, and not just the ones
bundled with Mercurial. Some of those extensions might not be as well-
behaved as the bundled ones…
--
Dan Villiom Podlaski Christiansen
danchr at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090731/cac12b08/attachment.bin
More information about the Mercurial-devel
mailing list