[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  
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