Cross-platform hgrc solution?

Question

I'm looking for a solution to have one .hgrc for mercurial to work in all my working environments(win/lin/mac), just like one vimrc to rule all.

It comes to a problem when I have to specify the path for some extensions, for example, hg-git:

on windows:

[extensions]
hggit = E:\hg-git\hggit

on linux/mac:

[extensions]
hggit = ~/hg-git/hggit

For vimrc, we have solution to distinguish different platform, like

if has('win32')
  ...
endif

Knowing that mercurial's hgrc is barely a normal ini file, I wonder if there is similar solution for hgrc file.

Or maybe some other solution?

Update

Thanks for mentioning using "custom environment variable instead of hard coding", that works for extensions' path.

However, to make extensions work is just one goal. I believe there are other configurations' behavior that depends on platform, like in http://www.ogre3d.org/docs/OGREDeveloperGuide/index.html, specific options are needed for Windows and Mac. How to solve this kind of problem?

Answer 1

How about using the .hgrc include mechanism and three separate files:

~/.hgrc
~/.hgrc-windows
~/.hgrc-linux

where the main ~/.hgrc has:

%include .hgrc-$OS

and then set $OS in your windows profile and your linux profile's. Alternately you could probably find an env variable that already exists on both systems ($USERNAME is usally already set in both windows and unix and may differ for you).

Answer 2

This is just in case you don't find a way to have only one .hgrc (or one set of .hgrc* files, per Oben Sonne's comment).

I only face Windows environments, so my mercurial.ini files are the same except for 1 path. I keep a copy in version control along with my Powershell profile script.

However, if I were faced with environments more varied, I would abstract the configuration to a script in a cross-platform language (e.g., Python) that overwrites the target .hgrc or mercurial.ini. I'd be able to have the pieces that have to be different for each OS/machine right next each other with easy ways of distinguishing which environment is current. Then I would keep that script in version-control to help keep the same version on each machine.

Since I don't change it often, I would probably execute it manually on each machine when I visited it next. For a larger number of machines or more frequent changes, I would have another script executed on login that pulls changes to the generating script from a central repo, and if there were indeed new changes pulled, update to tip and run the script.

(Heck, I'm now tempted to rig this kind of setup anyway.)

Answer 3

Why don't you just use a custom environment variable instead of hard coding the paths?