Unable to make it work on Django 1.10.3

[Ashish-Bansal]

Hi,

I'm unable to make it work with my django 1.10.3 setup.

I have added it to top of the INSTALLED_APPS.

INSTALLED_APPS = [
    'django_pdb',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.admin',
    'django_countries',
    'haystack',

and have added middleware class at the end :

MIDDLEWARE_CLASSES += ('django_pdb.middleware.PdbMiddleware',)

When I run it python manage.py runserver 0.0.0.0:8000 --pdb, it doesn't drop me into pdb shell.

Can anyone please help me in debugging why it's not working ? Is it a bug ? Or is it a configuration issue at my end ?

Regards, Ashish Bansal

[HassenPy]

hi there, sorry for the delay, was offline for some time now, i ll check this tomorrow evening.

[Ashish-Bansal]

@HassenPy

No problem. I understand :)

Thanks for the reply!

[HassenPy]

your configuration looks right, have you set settings.DEBUG = True ?

[Ashish-Bansal]

@HassenPy Yes

[Ashish-Bansal]

Moreover, recently I upgraded to Django 1.11.6. It's still not working.

[HassenPy]

are you using any app that is overriding the runserver command?

[Ashish-Bansal]

python manage.py runserver --help shows these optional arguments from pdb.

  --pdb                 Drop into pdb shell on at the start of any view.
  --ipdb                Drop into ipdb shell on at the start of any view. 

If django-pdb is able to insert the cli args to the runserver, doesn't that mean it hasn't been overridden by any other app ? (although I don't have any idea how it works internally).

are you using any app that is overriding the runserver command?

Sorry but I'm not really sure about that. Here's list of apps.

INSTALLED_APPS = [
    'django_pdb',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.admin',
    'django_countries',
    'haystack',
    'avatar',
    'authentication',
    'allauth',
    'allauth.account',
    'allauth.socialaccount',
    'compressor',
    'import_export',
    'djcelery',
    'allauth.socialaccount.providers.linkedin',
    'allauth.socialaccount.providers.google',
    'allauth.socialaccount.providers.github',
    'allauth.socialaccount.providers.facebook',
    'star_ratings',
    'taggit',
    'djstripe',
    'admin_honeypot',
    'djng',
    # wagtail apps
    'wagtail.wagtailforms',
    'wagtail.wagtailredirects',
    'wagtail.wagtailembeds',
    'wagtail.wagtailsites',
    'wagtail.wagtailusers',
    'wagtail.wagtailsnippets',
    'wagtail.wagtaildocs',
    'wagtail.wagtailimages',
    'wagtail.wagtailsearch',
    'wagtail.wagtailadmin',
    'wagtail.wagtailcore',
    'modelcluster',
    'oauth2_provider',
    'rest_framework',
    'adminsortable',
    'webpack_loader',
    'constance',
    'graphene_django',
    'rest_framework.authtoken',
    'debug_toolbar'
]

[HassenPy]

okey, just to make sure that it's the runserver command, does adding a pdb GET parameter to the url you're visiting drop you into a pdb shell? 127.0.0.1:8000/?pdb=True

[Ashish-Bansal]

Nope, it doesn't drop me into a pdb shell.

[HassenPy]

hey @Ashish-Bansal, looking at this now, found any leads?

[HassenPy]

also, please post your MIDDLEWARE_CLASSES

[Ashish-Bansal]

@HassenPy Nope, was busy with some office stuff. So, I didn't try to hack into source code.

[Ashish-Bansal]

MIDDLEWARE_CLASSES = [
    'djng.middleware.AngularUrlMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    // some other internal middlewares
]

MIDDLEWARE_CLASSES += ('django_pdb.middleware.PdbMiddleware',)

[HassenPy]

hey @Ashish-Bansal can you make sure that those "// some other internal middlewares" aren't blocking the middlewares that come after them?

For django 1.10+:
Make sure that all process_view are returning None. https://docs.djangoproject.com/en/1.10/topics/http/middleware/#process-view

It should return either None or an HttpResponse object. If it returns None, Django will continue processing this request, executing any other process_view() middleware and, then, the appropriate view. If it returns an HttpResponse object, Django won’t bother calling the appropriate view; it’ll apply response middleware to that HttpResponse and return the result.

For django < 1.10: Make sure that all process_view and process_request are returning None. https://docs.djangoproject.com/en/1.8/topics/http/middleware/#writing-your-own-middleware

[Ashish-Bansal]

If it returns an HttpResponse object, Django won’t bother calling the appropriate view; it’ll apply response middleware to that HttpResponse and return the result.

@HassenPy Oh so that explains it. Yes we are returning HttpResponse instead of None in one of our internal middleware. Thanks a lot for your support ! :)

I'll disable that middleware and try it. I'm closing this issue and will reopen it if it didn't work.

Moreover, you can add this info in the README, so that users can verify their internal middlewares if it doesn't work for them :)