Namespace package zope cannot find modules during testing

[FRidh]

In Nixpkgs we recently updated setuptools from 26.1.1 to 28.8.0 (and the issue also occurs with the latest 30.2.0). This seemed to break the testing of several zope modules for us. The modules do actually work, its just that when running python setup.py test we get import errors. Note that at this point we populate PYTHONPATH with all the dependencies. Any idea what could have caused this?

NixOS/nixpkgs#20791

[jaraco]

I suspect the offending release is v28.3.0, and in particular the work for #805. Can you confirm the issue only occurs on Python 3.3+? If so, that's almost certainly the cause.

The good news is that in #250, I'm making some progress in a better technique that will fully and properly address the behavior for Python 3.5+, and based on this ticket, I'll probably opt to revert the behavior from #805 for Python 3.3 and 3.4.

[FRidh]

Thanks for looking into this. The issue doesn't occur on 2.7, but it does indeed show up on 3.3, 3.4 and 3.5.

[jaraco]

Can you please retry with setuptools v31.0.0? One caution to consider is that any namespace packages must be installed from source or from wheels generated with setuptools 31 or later (or older than 28.3.0) due to #845.

[FRidh]

Now we get AttributeError: '_NamespacePath' object has no attribute 'sort'.

[FRidh]

so AttributeError: '_NamespacePath' object has no attribute 'sort' happens only with 3.5, not 2.7, 3.3 or 3.4.

[tseaver]

@jaraco We are seeing the 3.5-only failures as well in google-cloud-python.

[tseaver]

Looks like that has been opened as #885.

[FRidh]

This is broken again with 32.0.0, please reopen @jaraco

[FRidh]

To be more precise, it is only broken like this with 3.5 (and 3.6 although there we seem to get a new ModuleNotFoundError instead of ImportError).

[jaraco]

@FRidh: The issue described in this ticket was implicated by the change in 28.8.0, a change which has been backed out.

In 31.0.0, I've implemented an all new technique for handling namespace packages, which has tests, but which still had the additional issue reported in #885. That issue was solved in v31.0.1.

With 32.0.0, the only change was an unrelated to change with how MANIFEST.in files are processed, so should be unrelated. I suspect any issues you have with v32 will apply to 31.0.1.

If you're getting a new error, please file a new ticket describing the issue and how we can replicate it.