Mercurial is unable to load the mercurial_kerying extension due to errors in the import process. Reported the issue to setuptools, but was redirected here. Here is the traceback: ``` File "/usr/local/lib/python2.7/site-packages/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/local/lib/python2.7/site-packages/setuptools/extension.py", line 13, in <module> msvc9_support.patch_for_specialized_compiler() File "/usr/local/lib/python2.7/site-packages/setuptools/msvc9_support.py", line 24, in patch_for_sp ecialized_compiler unpatched.update(vars(distutils.msvc9compiler)) TypeError: vars() argument must have __dict__ attribute ``` Here is the setuptools bug report: https://bitbucket.org/pypa/setuptools/issue/305/error-during-import-of-mercurial-extension This is a suggestion from Jason R. Coombs > Mercurial's demandimport magic is probably implicated here. I suspect that the distutils.msvc9compiler is not yet a module, but is instead a stub created by demandimport as a placeholder for that module. Apparently, invoking vars() on such an object doesn't trigger the module to be realized, but instead causes the TypeError. > I think Setuptools' expectation here is valid and the issue lies with Mercurial and "demand import". I recommend that Mercurial exempt msvc9compiler from demand import or otherwise enhance the stubbed modules to support access of __dict__ or vars() invocations on them.
(setting to third-party - bugs related to third-party extensions are Not Our Problem even though they're allowed in our BTS) However, there's no reason for any part of setuptools to be loaded by Mercurial while loading an extension (or ever). I suspect you're pointing at the wrong file in your hgrc.
Hi Matt, Thanks for looking into this. The relevant area of my hgrc is this: [extensions] mercurial_keyring = The extension is installed via pip. I'll add this bug to mercurial-keyring and report.
I've figured this out. smf was able to reproduce this with highlight (when it loads pygments), and I started sniffing around. I've got a patch in progress.
Fixed by http://selenic.com/repo/hg/rev/2205d00b6d2b Augie Fackler <raf@durin42.com> demandimport: blacklist distutils.msvc9compiler (issue4475) This module depends on _winreg, which is windows-only. Recent versions of setuptools load distutils.msvc9compiler and expect it to ImportError immediately when on non-Windows platforms, so we need to let them do that. This breaks in an especially mystifying way, because setuptools uses vars() on the imported module. We then throw an exception, which vars doesn't pick up on well. For example: In [3]: class wat(object): ...: @property ...: def __dict__(self): ...: assert False ...: In [4]: vars(wat()) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-4-2781ada5ffe6> in <module>() ----> 1 vars(wat()) TypeError: vars() argument must have __dict__ attribute Which is similar to the problem we run into. (please test the fix)
Great! The patch works for me.
Bulk testing -> fixed