[PATCH 1 of 8] extdoc: separate module for handling extractions of descriptions

[Matt Mackall]

On Tue, 2009-07-07 at 01:47 +0200, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > On Tue, 2009-07-07 at 00:46 +0200, Martin Geisler wrote:
> >> Cédric Duval <cedricduval at free.fr> writes:
> >> 
> >> > # HG changeset patch
> >> > # User Cédric Duval <cedricduval at free.fr>
> >> > # Date 1246737838 -7200
> >> > # Node ID b48834a6d0e1c68ebe2bee05f5d24a424bfef40b
> >> > # Parent  10532b29cdee993efd804c7d60a188347425ebaf
> >> > extdoc: separate module for handling extractions of descriptions
> >> >
> >> > Moving moduledoc() from extensions, and adding synopsis(). This
> >> > module is meant to be used by both hg and external tools.
> >> 
> >> Perhaps we should write that in a comment at the top: This module
> >> should be importable without building the C extensions.
> >
> > Still not really excited about this whole approach. I'd actually
> > rather import modules (and tweak all the built-ins to be
> > random-import-friendly) than make our build uglier.
> 
> I must admit that I also think this is simpler -- I just somehow thought
> that this option was rejected earlier in the thread where Dan came up
> with the pydoc-solution...
> 
> As I see it, the only problem with importing modules is to figure out
> the list of importable modules. That we can do a build-time and amend it
> at run-time with os.listdir if we're dealing with normal .py files.

I don't think we should do anything with extensions at build-time.

> So why was it that we went away from this simple solution? :-)

Because it wasn't safe enough for the bitter end of the development
cycle.

-- 
http://selenic.com : development and support for Mercurial and Linux