Can I configure mercurial hooks like some extensions are configured in the hgrc file?

Question

I know how to specify which hooks are run when. What I want to know is if it is possible to pass config into the hook via the hgrc file. Extensions can do this, e.g.

[extensions]
someextension = something

[someextension]
some.config = 1
some.other.config = True

I want to be able to do something similar for hooks, e.g.

[hooks]
changegroup.mail_someone = python:something

[changegroup.mail_someone]
to_address = [email protected]

Is something like this possible? Searching for a way to do this hasn't turned up anything useful... If it is possible, how do I go about reading in the config in my (Python in-process) hook handler?

Karlsbad

Answer 1

Let me answer for both hook types:

• An in-process hook would use ui.config and the related methods to read the config values:

  address = ui.config('changegroup.mail_someone', 'to_address')
  

  You can also use ui.configbool and ui.configlist to read Booleans and lists, respectively.

• An external hook can use hg showconfig to extract the configuration value:

  $ hg showconfig changegroup.mail_someone.to_address
  

  That will return [email protected] on stdout. You can use

  $ hg showconfig changegroup.mail_someone
  

  to see all settings in that particular section.

Primordial

Thanks. That's handy. Presumably, you can access this in almost the same way with an internal hook by doing os.popen('hg showconfig mail_someone.to_address')? – Karlsbad

@Spycho: sure, you can do that. But for an internal hook you already have a ui object and so you can call ui.config('mail_someone', 'to_address') directly. – Primordial

ah, awesome. That's simpler. I thought I read somewhere that the internal mercurial methods that you can get at through ui and repo parameters aren't supposed to be used because they can break without notice? Is that not what mercurial.selenic.com/wiki/MercurialApi is about? Or is this not considered part of "Mercurial's internal API"? – Karlsbad

@Spycho: you're right that the internal API (that's all the Python code) can change from release to release. If you're afraid of that, then don't use an in-process hook. If you do use an in-process hook, then I assume you want the extra speed and convenience of using the internal API. The API doesn't change that often, but it can change and you'll have to test your hook with each new Mercurial release. – Primordial

Couldn't you use an in-process hook and not use the internal API? I.e. use the command line API instead, via os.popen? That way, it's in-process, but uses the stable API? os.popen will obviously be less efficient that the internal API, but it will probably still be more efficient than using an external hook? – Karlsbad

Well, you could do that... I would say that that it's only marginally more efficient than letting Mercurial run your Python script as an external hook, especially if you're going to spawn new hg processes from your in-process hook. – Primordial

It's presumably easier though. Rather than having to faf around with $HG_<some var> as an env variable, you get it as a kwarg. – Karlsbad

@Spycho: fair enough, that's slightly easier. Not much compared to grabbing the values out of os.environ, but that's a matter of taste :-) Feel free to accept the answer if you felt it answered your (original) question. – Primordial

I submitted an edit which detailed how to do it (via ui.config or os.popen), but it seems to have not made it into the answer. If we add the discussed options of how to achieve this with an internal hook (which is what my question was asking), along with the warning that ui.config might break between mercurial versions, I'll be happy to accept it. – Karlsbad

Oh, I didn't notice that you asked about an in-process hook. The = something instead of = python:something threw me off track. I've updated the answer to make it much more clean, hope you like it now. Btw, ui.config is not unstable and wont change radically — tons of extensions already use this API and we try not to make life too difficult for extension writers. – Primordial

Ah excellent. I wasn't sure quite how frequently API breaking changes were made, given the warning message in the docs. – Karlsbad