pkgutil importlib migration test was failing on Windows buildbots

[ncoghlan]

BPO	15384
Nosy	@brettcannon, @birkenfeld, @db3l, @ncoghlan

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-07-20.01:17:20.580>
created_at = <Date 2012-07-18.10:46:02.746>
labels = ['invalid', 'type-bug', 'library']
title = 'pkgutil importlib migration test was failing on Windows buildbots'
updated_at = <Date 2012-07-20.01:17:20.579>
user = 'https://github.com/ncoghlan'

bugs.python.org fields:

activity = <Date 2012-07-20.01:17:20.579>
actor = 'ncoghlan'
assignee = 'none'
closed = True
closed_date = <Date 2012-07-20.01:17:20.580>
closer = 'ncoghlan'
components = ['Library (Lib)']
creation = <Date 2012-07-18.10:46:02.746>
creator = 'ncoghlan'
dependencies = []
files = []
hgrepos = []
issue_num = 15384
keywords = []
message_count = 4.0
messages = ['165752', '165758', '165797', '165894']
nosy_count = 4.0
nosy_names = ['brett.cannon', 'georg.brandl', 'db3l', 'ncoghlan']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'test needed'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15384'
versions = ['Python 3.3']

[ncoghlan]

As noted in bpo-15314, one of the pkgutil tests was failing on Windows because pkgutil.get_importer("") was returning None. On my Fedora system it returns FileFinder(".").

I've now tweaked that particular test to use a bogus path string so that None is the expected result on all platforms.

However, the cross-platform discrepancy is a little disturbing - I would have expected the operation to either fail or succeed regardless of platform.

Since pkgutil.get_importer is now just a wrapper that takes care of checking path_importer_cache and then walking sys.path_hooks, I believe the actual culprit is FileFinder.path_hook()("") returning None (I'm currently downloading and installing 3.3b1 on my gaming machine to confirm that)

[ncoghlan]

Well, that's weird. A manual test on my Windows 7 gaming rig indicates that the old test *should* have worked on Windows as well.

I have no idea how to investigate this further. David, are you able to check what pkgutil.get_importer("") returns when running locally on your Windows buildbots?

An example of the error the buildbots were getting: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/5450/steps/test/logs/stdio

[db3l]

With a local build on my buildbot of the tip of the default branch, pkgutil.get_importer('') returns FileFilter('.'). The tests also passed.

However, after checking here and realizing the offending code had been removed from the test, I put it back in and it still fails.

I think the problem is that sys.path[0] is not '' when testing in the buildbot environment (though it is when I run the debug interpreter interactively). Within the buildbot scripts it's a path to the stdlib test zip, so for example in my test tree it's "D:\cygwin\home\db3l\test\build\PCbuild\python33_d.zip".

And if I hand that string to pkgutil.get_importer() I do seem to get None back.

[ncoghlan]

Ah, that makes sense - since the zip file doesn't exist on buildbots, returning None is the correct result.

Mystery explained, thanks :)