view tests/test-bugzilla.t @ 29642:8960fcb76ca4 stable

demandimport: avoid infinite recursion at actual module importing (issue5304)

Before this patch, importing C module on Windows environment causes
infinite recursion call, if py2exe is used with -b2 option.

At importing C module "a.b", extra hooking by zipextimporter of py2exe
causes:

  0. assumption before accessing "b" of "a":

     - built-in module object is created for "a",
       (= "a" is actually imported)
     - _demandmod is created for "a.b" as a proxy object, and
       (= "a.b" is not yet imported)
     - an attribute "b" of "a" is initialized by the latter

  1. invocation of __import__ via _hgextimport() in _demandmod._load()
     for "a.b" implies _demandimport() for "a.b"

     This is unintentional, because _demandmod might be returned by
     _hgextimport() instead of built-in module object.

  2. _demandimport() at (1) is invoked with not context of "a", but
     context of zipextimporter

     Just after invocation of _hgextimport() in _demandimport(), an
     attribute "b" of the built-in module object for "a" is still
     bound to the proxy object for "a.b", because context of "a" isn't
     updated by actual importing "a.b". even though the built-in
     module object for "a.b" already appears in sys.modules.

     Therefore, chainmodules() returns _demandmod for "a.b", which is
     gotten from the attribute "b" of "a".

  3. processfromitem() on "a.b" causes _demandmod._load() for "a.b"
     again

     _demandimport() takes context of "a" in this case.

     Therefore, attributes below are bound to built-in module object
     for "a.b", as expected:

     - "b" of built-in module object for "a"
     - _module of _demandmod for "a.b"

  4. but _demandimport() invoked at (1) returns _demandmod object

     because _demandimport() just returns the object returned by
     chainmodules() at (3) above.

  5. then, _demandmod._load() causes infinite recursion call

     _demandimport() returns _demandmod for "a.b", and it is "self" at
     _demandmod._load().

To avoid infinite recursion at actual module importing, this patch
uses self._module, if _hgextimport() returns _demandmod itself. If
_demandmod._module isn't yet bound at this point, execution should be
aborted, because actual importing failed.

In this patch, _demandmod._module is examined not on _demandimport()
side, but on _demandmod._load() side, because:

  - the former has some exit points
  - only the latter uses _hgextimport(), except for _demandimport()

BTW, this issue occurs only in the code path for non .py/.pyc files in
zipextimporter (strictly speaking, in _memimporter) of py2exe.

Even if zipextimporter is enabled, .py/.pyc files are handled by
zipimporter, and it doesn't imply unintentional _demandimport() at
invocation of __import__ via _hgextimport().

mock bugzilla driver for testing template output:

  $ cat <<EOF > bzmock.py
  > from __future__ import absolute_import
  > from mercurial import extensions
  > 
  > def extsetup(ui):
  >     bugzilla = extensions.find('bugzilla')
  >     class bzmock(bugzilla.bzaccess):
  >         def __init__(self, ui):
  >             super(bzmock, self).__init__(ui)
  >             self._logfile = ui.config('bugzilla', 'mocklog')
  >         def updatebug(self, bugid, newstate, text, committer):
  >             with open(self._logfile, 'a') as f:
  >                 f.write('update bugid=%r, newstate=%r, committer=%r\n'
  >                         % (bugid, newstate, committer))
  >                 f.write('----\n' + text + '\n----\n')
  >         def notify(self, bugs, committer):
  >             with open(self._logfile, 'a') as f:
  >                 f.write('notify bugs=%r, committer=%r\n'
  >                         % (bugs, committer))
  >     bugzilla.bugzilla._versions['mock'] = bzmock
  > EOF

set up mock repository:

  $ hg init mockremote
  $ cat <<EOF > mockremote/.hg/hgrc
  > [extensions]
  > bugzilla =
  > bzmock = $TESTTMP/bzmock.py
  > 
  > [bugzilla]
  > version = mock
  > mocklog = $TESTTMP/bzmock.log
  > 
  > [hooks]
  > incoming.bugzilla = python:hgext.bugzilla.hook
  > 
  > [web]
  > baseurl=http://example.org/hg
  > 
  > %include $TESTTMP/bzstyle.hgrc
  > EOF

  $ hg clone -q mockremote mocklocal

push with default template:

  $ echo '[bugzilla]' > bzstyle.hgrc
  $ echo foo > mocklocal/foo
  $ hg ci -R mocklocal -Aqm 'Fixes bug 123'
  $ hg -R mocklocal push -q
  $ cat bzmock.log && rm bzmock.log
  update bugid=123, newstate={}, committer='test'
  ----
  changeset 7875a8342c6f in repo $TESTTMP/mockremote refers to bug 123. (glob)
  details:
  	Fixes bug 123
  ----
  notify bugs={123: {}}, committer='test'

push with style:

  $ cat <<EOF > bzstyle.map
  > changeset = "{node|short} refers to bug {bug}."
  > EOF
  $ echo "style = $TESTTMP/bzstyle.map" >> bzstyle.hgrc
  $ echo foo >> mocklocal/foo
  $ hg ci -R mocklocal -qm 'Fixes bug 456'
  $ hg -R mocklocal push -q
  $ cat bzmock.log && rm bzmock.log
  update bugid=456, newstate={}, committer='test'
  ----
  2808b172464b refers to bug 456.
  ----
  notify bugs={456: {}}, committer='test'

push with template (overrides style):

  $ cat <<EOF >> bzstyle.hgrc
  > template = Changeset {node|short} in {root|basename}.
  >            {hgweb}/rev/{node|short}\n
  >            {desc}
  > EOF
  $ echo foo >> mocklocal/foo
  $ hg ci -R mocklocal -qm 'Fixes bug 789'
  $ hg -R mocklocal push -q
  $ cat bzmock.log && rm bzmock.log
  update bugid=789, newstate={}, committer='test'
  ----
  Changeset a770f3e409f2 in mockremote.
  http://example.org/hg/rev/a770f3e409f2
  
  Fixes bug 789
  ----
  notify bugs={789: {}}, committer='test'