AttributeError: 'module' object has no attribute '__file__' (own module installed using pip)

Question

We have a Python 2 module which we build using python setup.py sdist, then deploy to a remote machine and install inside a virtualenv using pip install mymodule.tar.gz.

The problem is: on one machine the resulting module knows its own filepath __file__, and on another machine it doesn't. The test case is this:

python -c "import mymodule; print(mymodule.__file__)"

On one machine it correctly prints the full path to a location inside the virtualenv "site-packages". On another very similar machine it raises:

AttributeError: 'module' object has no attribute '__file__'

(The machines in question are AWS EC2 nodes running Ubuntu 14.04.)

The problem was seen when trying to resolve a path using pkg_resources by doing python -c "import pkg_resources; print(pkg_resources.resource_filename('mymodule', 'migrations'))" - this should give the full path to the module's code, but doesn't resolve properly on the problematic machine.

I can't see any differences in the shell environment, the set of packages installed by pip, or the filesystem for "mymodule" after it's been installed by pip. I've cded to an empty folder to make sure I'm not importing anything from cwd.

What differences can I investigate to trace this issue? How can I ensure that my pip install installs a package that knows its filepath?

Answer 1

The source of the problem for us was actually that we were installing two modules, and Python appears to have an ordering ambiguity. We designed and installed these two modules as separate codebases:

mymodule
mymodule.crazything

In other words, the latter is a standalone package adding a submodule to mymodule. This means that when the latter is compiled, it creates a virtual mymodule with no content.

When installing both these packages, there are then two separate mymodule modules installed. Which of these will be the one in use when you run import mymodule? As far as I can tell this is undefined by Python and it is locally consistent but not consistent across machines.

The solution for us was: don't create separate packages with submodules in. Instead we give them separate module identities that don't clash.