[global variables]
> one possible approach might be: Have those bindings be instance variables in a Database class in
> database.py, and have a module-level binding to an instance of it. Then, tests can have their
> own instance which is thrown away aftereach test.
I’m not sure we can do that, or that I understand the suggestion.  If you’re talking about how pprint/textwrap/reprlib use a module-level instance to offer module-level functions with some defaults, I think the database module can’t work that way.  We have module-level classes (Distribution and EggInfoDistribution, no inheritance) and module-level functions (get_distribution, the one in the failing test, for example) which may use any of the four caches and return instances of either class.  If I understand your suggestion correctly, you’d move database._cache_egg to database.EggInfoDistribution._cache, and maybe change the code to move the cache logic to the *Distribution classes instead of in the various functions (thus implementing a singleton registry like logging loggers.  I like this idea.

Writing this made me think of another possible solution: dependency injection!  Just like the functions have a paths argument that defaults to sys.path if None is passed, I could change the internal cache generation function to take arguments for the four caches, so that the tests could pass fresh dictionaries that would not be shared between tests, unlike database-module-level global objects.

> This problem was not trivial to find, because it appears that test execution order may not be
> entirely deterministic: I couldn't see any other reason why the flag would have different values
> on different machines.
Sorry, what flag?

> I believe that you (Éric) had difficulty reproducing it.
More than difficulty: I have not yet reproduced it.  The tests pass on my OS, Debian x86_64 with linux3.  I’ve installed Arch but not cloned/built Python yet.

> Perhaps we don't need to re-implement, but instead add more tests around cache invalidation
> and cache contents.
The packaging database cache API is not fantastic.  Libraries or applications can turn it off entirely, or clear it so that sys.path gets scanned again.  I’m not even sure that our tests do the right thing: They disable the cache in setUp and re-enable it in cleanup, but maybe they should just clear it in cleanup.  (BTW I have added a regrtest check to make sure the cache is re-enabled and clean after tests run.)  In any case, we don’t have tests that check the behavior of the database module with respect to caching.

“There are only two hard problems in Computer Science: cache invalidation and naming things” (Phil Karlton), and I’m less bad at the latter.  The student who implemented most of the database module is not active in our group anymore, but Michael Mulich, who started the module but did not write the cache code, still is.  So there’s hope that we can fix this together (and thanks for all the reports, diagnosis and suggestions so far!).

> Re. Paul Moore's comment - IMO he's right about the problem, but changing only
> packaging.manifest._translate_pattern doesn't do it. The equivalent fix has to be made in
> distutils.filelist.translate_pattern. I've made the change in the pythonv branch, and the test no
> longer fails.
Patches for upstream cpython would be most helpful.  I also think that fixing bugs in the pythonv branch makes it harder to review.