Possible bug introduced in Django 1.7 admin/docs?

[Christopher Welborn]

I was just playing around after upgrading from 1.6.6, I made small
changes to my source to make it compatible. It was using the old
WSGIHandler() style for wsgi.py, so I switched to
get_wsgi_application(). I upgraded django-debug-toolbar, because it was
incompatible. Everything on my site works. The admin works. Some of the
admin/doc stuff works. However, when visiting admin/doc/filters this
happened:


Internal Server Error: /admin/doc/filters/
Traceback (most recent call last):
File
"/home/cjwelborn/lib/python3.3/django/core/handlers/base.py", line 111,
in get_response
response = wrapped_callback(request, *callback_args,
**callback_kwargs)
File
"/home/cjwelborn/lib/python3.3/django/views/generic/base.py", line 69,
in view
return self.dispatch(request, *args, **kwargs)
File "/home/cjwelborn/lib/python3.3/django/utils/decorators.py",
line 29, in _wrapper
return bound_func(*args, **kwargs)
File
"/home/cjwelborn/lib/python3.3/django/contrib/auth/decorators.py", line
22, in _wrapped_view
return view_func(request, *args, **kwargs)
File "/home/cjwelborn/lib/python3.3/django/utils/decorators.py",
line 25, in bound_func
return func.__get__(self, type(self))(*args2, **kwargs2)
File
"/home/cjwelborn/lib/python3.3/django/contrib/admindocs/views.py", line
43, in dispatch
return super(BaseAdminDocsView, self).dispatch(*args, **kwargs)
File
"/home/cjwelborn/lib/python3.3/django/views/generic/base.py", line 87,
in dispatch
return handler(request, *args, **kwargs)
File
"/home/cjwelborn/lib/python3.3/django/views/generic/base.py", line 154,
in get
context = self.get_context_data(**kwargs)
File
"/home/cjwelborn/lib/python3.3/django/contrib/admindocs/views.py", line
100, in get_context_data
load_all_installed_template_libraries()
File
"/home/cjwelborn/lib/python3.3/django/contrib/admindocs/views.py", line
314, in load_all_installed_template_libraries
for p in os.listdir(os.path.dirname(upath(mod.__file__)))
AttributeError: 'module' object has no attribute '__file__'


It doesn't seem to touch any of my stuff, or any of the changes I
mentioned previously. Only Django's stuff. Any ideas?

--
\¯\ /¯/\
\ \/¯¯\/ / / Christopher Welborn (cj)
\__/\__/ / cjwelborn at live·com
\__/\__/ http://welbornprod.com

[Christopher Welborn]

On 09/18/2014 10:32 PM, I wrote:
> Internal Server Error: /admin/doc/filters/

> "/home/cjwelborn/lib/python3.3/django/contrib/admindocs/views.py", line
> 314, in load_all_installed_template_libraries
> for p in os.listdir(os.path.dirname(upath(mod.__file__)))
> AttributeError: 'module' object has no attribute '__file__'

It does it for admin/doc/tags also. Not /models, /views, or /bookmarklets.

[James Bennett]

Are you using any third-party libraries which were installed as eggs?

[Christopher Welborn]

On 09/18/2014 10:50 PM, James Bennett wrote:
> Are you using any third-party libraries which were installed as eggs?
>

It looks like I have several...

Third-party extensions:
django-extensions 1.3.3
django-solo 1.0.5

Non-extensions, but dependencies of extensions:
sqlparse 0.1.11 (django-debug-toolbar dependency)
user_agents 0.2.0 (local extension dependency)
ua_parser 0.3.5 (local extension dependency)

Non-extensions, but imported:
pyscopg2 2.5.2
pytidylib 0.2.3
twython 3.1.2

I am basing this on the fact that these all have [module-name].egg-info
in my /dist-packages/ dir. I have a couple others that have no .egg-info.

[Christopher Welborn]

On 09/18/2014 10:50 PM, James Bennett wrote:

> Are you using any third-party libraries which were installed as eggs?
>

Sorry, but was that supposed to be a hint to say "Don't use eggs"? I can
see why it may fail looking for '__file__', but I don't understand
why that is acceptable. Surely there should be some graceful error
handling in the case that '__file__' is not available, instead of a
hard 500 internal server error.

Like if a third-party extension errors while looking for tags and
filters, the extension would be skipped instead of halting.

This is what made me think it was a bug. I don't want to file one if
it's not though, so could someone enlighten me please? I am being
sincere. Maybe I could even offer a patch for it.

[Russell Keith-Magee]

On Sat, Sep 20, 2014 at 2:17 AM, Christopher Welborn <cjwe...@live.com> wrote:

On 09/18/2014 10:50 PM, James Bennett wrote:
> Are you using any third-party libraries which were installed as eggs?
>

Sorry, but was that supposed to be a hint to say "Don't use eggs"? I can
see why it may fail looking for '__file__', but I don't understand
why that is acceptable. Surely there should be some graceful error
handling in the case that '__file__' is not available, instead of a
hard 500 internal server error.

Like if a third-party extension errors while looking for tags and
filters, the extension would be skipped instead of halting.

This is what made me think it was a bug. I don't want to file one if
it's not though, so could someone enlighten me please? I am being
sincere. Maybe I could even offer a patch for it.

Everything you say is true. Errors of this nature *can* be caught, and *could* be worked around. This sort of error *could* be considered a bug.

However, the experience of the Django core team over the last 9 years has been that eggs are just more trouble than they're worth. We've tried to accommodate them in the past in various ways  - there is, for example an egg-based template loader. 

I doubt we'd close egg-related issues as a wontfix - but they're also not getting a whole lot of attention, either. We don't pre-emptively do a whole lot of specific testing for egg-related problems. If someone reports a problem and provides a fix and test, we'll include it in our codebase; but actively looking for egg-related issues isn't high on the priority list.

This is then compounded by the fact that the use of eggs is generally decreasing. They were popular 10 years ago when easy_install was king; these days, we use pip install, and wheels are the endorsed Python way for installing packages.

So - James' comment should be interpreted as "Are you using eggs? Well, there's your first problem". If you're actually using eggs, I'd strongly encourage you to consider why, because there's almost certainly a better way to distribute your code, and that way won't involve the random bugs that eggs introduce.

Also - to clarify; existence of an .egg-info file doesn't *necessarily* mean you're using an egg - for historical reasons, the .egg-info file is used for other packaging purposes.

Yours,

Russ Magee %-)

[Christopher Welborn]

On 09/19/2014 08:26 PM, Russell Keith-Magee wrote:
> So - James' comment should be interpreted as "Are you using eggs? Well,
> there's your first problem". If you're actually using eggs, I'd strongly
> encourage you to consider why, because there's almost certainly a better
> way to distribute your code, and that way won't involve the random bugs
> that eggs introduce.
>
> Also - to clarify; existence of an .egg-info file doesn't *necessarily*
> mean you're using an egg - for historical reasons, the .egg-info file is
> used for other packaging purposes.
>
> Yours,
> Russ Magee %-)
>

Thank you for that response. You spelled it out perfectly. I'll look
into my libraries and installation methods to see if there is something
I can do on my end to help with my error.