Does importlib_resources work for namespace packages?

[jaraco]

In GitLab by @warsaw on Nov 3, 2017, 20:26

This error message

Technically speaking, I think this can also happen for namespace packages, which are packages, but which shouldn't be usable as an anchor for importlib_resources. So I think this error message might need to change.

[jaraco]

In GitLab by @brettcannon on Dec 8, 2017, 13:10

changed the description

[jaraco]

In GitLab by @warsaw on Dec 8, 2017, 13:14

changed the description

[jaraco]

In GitLab by @warsaw on Dec 8, 2017, 13:14

changed the description

[jaraco]

In GitLab by @warsaw on Dec 8, 2017, 13:18

changed title from {-Pedantic error message-} to {+Does importlib_resources work for namespace package?+}

[jaraco]

In GitLab by @warsaw on Dec 8, 2017, 13:21

changed title from Does importlib_resources work for namespace package? to Does importlib_resources work for namespace package{+s+}?

[jaraco]

In GitLab by @brettcannon on Dec 8, 2017, 13:23

Namespace packages will fail eventually, but it will come up as an AttributeError when trying to read get_data() on None for the loader. We should definitely have a test case and quite possibly have a check in _get_package() that if __spec__ is set that loader is not None.

[jaraco]

In GitLab by @warsaw on Dec 8, 2017, 14:06

@brettcannon and I are in agreement, namespace packages can't have resources. If we want to relax this later, we can.

[jaraco]

In GitLab by @brettcannon on Dec 8, 2017, 17:01

There actually is a loader for namespace packages but it isn't being set on their spec:

Python 3.6.3 (default, Oct  4 2017, 06:09:15) 
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.mkdir('bunk')
>>> import bunk
>>> bunk.__spec__.loader
>>> bunk.__loader__
<_frozen_importlib_external._NamespaceLoader object at 0x101a8a588>

[jaraco]

In GitLab by @brettcannon on Dec 8, 2017, 17:05

So the question now becomes do we want to make this work? The problem is that if a namespace package spans a file system directory and a zip file then how the heck do we get the appropriate loader for either? Since namespace packages are really just a placeholder for __path__ and nothing else we don't get to have a concrete loader that knows how to handle the things next to the package since the package spans multiple locations. Compare this to a package that defines an __init__.py which gives us a concrete location to look in.

[jaraco]

In GitLab by @warsaw on Dec 13, 2017, 10:05

assigned to @warsaw

[jaraco]

In GitLab by @warsaw on Dec 13, 2017, 11:26

mentioned in commit a48726b0a285c92a624b563aedb590ea9af80d10

[jaraco]

In GitLab by @warsaw on Dec 13, 2017, 11:27

mentioned in merge request !50

[jaraco]

In GitLab by @warsaw on Dec 13, 2017, 11:30

I have a MR that properly prevents namespace packages from having resources. Along the way I filed bugs for a couple of inconsistencies in namespace package metadata:

• inconsistent __loader__ and __spec__.loader
• inconsistent __file__ and __spec__.origin

[jaraco]

In GitLab by @warsaw on Dec 13, 2017, 14:59

closed via commit b5f1b15

[jaraco]

In GitLab by @warsaw on Dec 13, 2017, 14:59

closed via merge request !50

[jaraco]

In GitLab by @dgreiman on Dec 18, 2017, 17:54

If someone came up with a patch to add support for namespaces, would it be considered?

I agree it would be hairy, but all of the google-cloud-* packages are namespace packages, so I'm motivated to get this to work.