[PATCH 0 of 6] Build documentation using distutils - v3

Dan Villiom Podlaski Christiansen danchr at gmail.com
Sun Nov 29 16:52:44 CST 2009


On 29 Nov 2009, at 20:11, Martin Geisler wrote:

> Dan Villiom Podlaski Christiansen <danchr at gmail.com> writes:
> 
> Hi Dan,
> 
> I've looked at the patches again...
> 
>> This is an updated version of my distutils-docutils-marriage
>> patch. The primary changes are:
>> 
>> * The package data is now installed as actual package data instead of
>>  regular data.
> 
> This should be nice, but it breaks 'make local' since the package data
> is now build directly in the directory created by distutils.

Oops, yeah, I'll test that too. Instead of changing the build process, wouldn't it be better to make the Makefile do an install for ‘make local’?

> The install_package_data class in setup.py was introduced way back in
> changeset 2653740d8118 (2005) in order work around the lack of
> package_data in Python 2.3.
> 
> Now that we require Python 2.4 we could begin using package_data. But I
> think the "correct" way is to move the package data into the package:
> 
>  templates/ -> mercurial/templates/
>  help/      -> mercurial/help/
> 
> We have two other directories which we currently put into data_files:
> 
>  i18n/      -> mercurial/i18n/   (actually not used at runtime)
>  locale/    -> mercurial/locale/ (not in repo, generated)
> 
> I just searched my system and we are the only piece of software on the
> entire system that ship .po files. I suggest we stop doing that and move
> templates/ and help/ into mercurial/.
> 
> The advantage of moving those directories is that we no longer have to
> search for the correct directory such as it's currently done in
> templater.py, i18n.py, and help.py.

How about turning ‘templater’, ‘i18n’ & ‘help’ into packages? That is, the Python files would be renamed from ‘X.py’ to ‘X/__init__.py’, and the data files would then be located/generated within that package? The ‘help’ module should see the greatest benefit for this, in my opinion, as it would become much more obvious where to put documentation sources.

> Also, you now register the files under templates/, help/, i18n/ in the
> run method of the build_mo class. That seems a bit icky since build_mo
> has nothing to do with templates or the help topics.

Yes, this is to avoid traversing the directories on *every* run of ‘setup.py’ — even if just printing out help. Would you rather I rename the command, or move the traversal into a separate command?

>> * Both documentation & manual locations are fully customisable, and
>>  the values may refer to distutils configuration variables.
> 
> I like the idea about installing man pages in the right location. I
> never install third-party software system-wide like that, but I suppose
> others might be brave enough to do that...

Personally, I install stuff into either /opt/<whatever> or a similar path in my home directory. Then, I have initialisation scripts which add these paths as needed. I figured the main benefits of this would be to packagers and Windows users; less custom hackery for the former and no reliance on GNU-ware for the latter. Essentially, installing an egg of Mercurial would get you All The Good Stuff™ :)

>> * The RPM build specification has been updated to use distutils
>>  exclusively. In theory, it works; I haven't been able to test it.
> 
> Okay, I have also no clue about RPM packages... What does our RPM guys
> say to this?

That I need to put some shell escapes/quotes in there :)

>> * The HTML documentation no longer includes the manual category in the
>>  filenames.
> 
> I can see how that is nice, but it's not a change you should lump
> together with the rest -- Matt will have to install a small mod_rewrite
> rule on the webserver if the files go online under new names. I've
> linked to the old names in tons of mails and answers on StackOverflow
> and I don't want those links to break :-)

Ah, will do!

--

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/20091129/fd7ebbc9/attachment.bin>


More information about the Mercurial-devel mailing list