AttributeError: 'module' object has no attribute '__file__' (django\utils\translation\

Issue #173 open
Andrey Pochekutov
created an issue

i have config:



INSTALLED_APPS = ( 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.admin', 'django.contrib.messages', 'django.contrib.markup', 'sorl.thumbnail', 'debug_toolbar', 'piston',

... ) }}}

start project in virtual env:



virtualenv --no-site-packages --distribute .env pip install -E .env django django-debug-toolbar sorl-thumbnail trans simplejson pip install -E .env hg+

}}} run server, and got error:

... File "c:\projects\repos\mypersonal\y2010\avrorakras.env\lib\site-packages\dja ngo\utils\translation\", line 176, in translation default_translation = _fetch(settings.LANGUAGE_CODE) File "c:\projects\repos\mypersonal\y2010\avrorakras.env\lib\site-packages\dja ngo\utils\translation\", line 160, in _fetch apppath = os.path.join(os.path.dirname(app.file), 'locale') AttributeError: 'module' object has no attribute 'file'

This error in code, where appname is piston: {{{


    for appname in settings.INSTALLED_APPS:
        app = import_module(appname)
        apppath = os.path.join(os.path.dirname(app.__file__), 'locale')


after i add empty file to .env\Lib\site-packages\piston\ server run successfily

Comments (31)

  1. jmagnusson

    I'm getting this even though I have applied Brodie's patch:

    /usr/local/Cellar/python/2.7.1/lib/python2.7/site-packages/virtualenvwrapper/ UserWarning: Module piston was already imported from None, but /Users/[user]/Sites/event/src/django-piston is being added to sys.path

    I'm on Python 2.7.1 and using Django 1.3 final.

  2. Anonymous

    This issue appears to be in 0.2.3. I got it when doing ./ runserver. Downgraded to 0.2.2 and problem went away. Using virtualenv ( fairly recent ) and Django 1.3.1.

  3. Anonymous

    Same issue with me. Piston 0.2.3 on Django 1.4 alpha (svn trunk Rev: 17047). Downgrading to 0.2.2 works just fine.

  4. SocialCode

    Hi folks -

    So this isn't actually a Piston issue.

    Piston uses a packaging feature of setuptools called which allows you to have multiple packages installed that share a common package namespace. When you install Piston using pip, it ignores the and creates an nspkg.pth file in site-packages like so:

    $ pip install django-piston
    Downloading/unpacking django-piston
      Downloading django-piston-0.2.3.tar.gz
      Running egg_info for package django-piston
    Installing collected packages: django-piston
      Running install for django-piston
        Skipping installation of $VIRTUAL_ENV/lib/python2.6/site-packages/piston/ (namespace package)
        Installing $VIRTUAL_ENV/lib/python2.6/site-packages/django_piston-0.2.3-py2.6-nspkg.pth
    Successfully installed django-piston
    Cleaning up...

    So when Django's i18n engine looks for piston.__file__ , it doesn't find it - Piston doesn't get imported the way a plain Python package does because of the nspkg.pth file. When you use to install it, the file does get included, so piston.__file__ is then defined. Django should not be relying upon that attribute being defined.

    This is being tracked in the Django bug tracker:

    I'm looking into whether there are packages out there that rely upon Piston being a namespaced package (removing it as the fork has done would be backward incompatible to other packages that install themselves in the piston namespace), but for the time being, I can't accept this patch.


  5. Mikhail Lukianchenko

    Django realy should not wark this way. But world is not perfect. You can't say the problem doesn't exists just beacause upstream dependancy works in some non-standard or non-obvious maner. This issue renders Piston unusable for projects with I18L support enabled, namely almost any multi-language project.

  6. Joshua Ginsberg

    There's an easy workaround: don't use pip to install it. I'm hoping to discover how much the namespace_package feature is relied upon, because I don't like introducing backward incompatibilities, but I'm inclined to agree that we should work around Django's bug.

  7. danros
    • changed status to open

    Regardless of what breakage *may* occur with this patch, the unfortunate reality is that piston is broken when installing using the most common installation method. This surely trumps everything else?

    I know piston to be good software so I do the trivial workaround of 'touch'. A newcomer however might dismiss piston as 'broken' and look elsewhere, which would be a shame.

  8. Nuno Khan

    guys i dont understand comment #16 ,can you elaborate a bit further? i installed pip, but after i got this error i downloaded the latest src and still gives me the same error. what should i do? i am using django 1.4

  9. Log in to comment