I thought I'd go back and look at your original post. Your settings file looks a bit tricky.

I learned to deal with multiple settings files a long time ago so I don't know what current best practice is. Essentially, the way I do it is to have a complete base.py with all settings in a default state for security and production components. Then I have all my separate settings files ...

from base import *

... followed by the adjusted settings for that environment. Typically they will be production.py, staging.py and local.py

Then depending on the environment my wsgi.py imports settings.production or settings.mike-local or whatever.

It looks to me as though you are doing the opposite. Your wsgi.py imports a single settings file which has a massive if/elif block to import one of a multitude of other settings files each of which imports the equivalent of my base.py (your settings_common.py)

My mechanism has a single import statement while yours has at least two.

I think your wsgi.py should have the massive if/elif block to simply name the correct settings file (based on the host name) whenever the web server reloads.

It might reduce importing complexity somewhat and possibly solve the problem.

My settings arrangement is

base - all the settings as defaults
production - all the production settings no matter which host
staging - all the staging settings no matter which host
local - all the local settings including detecting the OS, setting DEBUG switching off security etc
local-mike - all my own settings including sqlite for faster testing
local-test - including postgreSQL for rigorous testing

I also needed to simulate environments. My mechanism is to rename the project directory and detect that in my settings.base.py like this ...

if deploy_dir == 'bis':     # pragma: no cover
    PRODUCTION = "pq3"    # hostname
    DOMAIN = 'djfghdsgdlg.com'
    BRANDING = 'BIS'
    BRAND_URL = 'https://www.{0}/'.format(DOMAIN)
    ADMIN_URL = 'https://pay.{0}/admin'.format(DOMAIN)
    ALLOWED_HOSTS = [u'pay.{0}'.format(DOMAIN)]
    FUNCTION = 'invoice'
elif deploy_dir == 'cli':     # pragma: no cover
    etc etc

I also wrote a couple of utilities which are called from dev versions of my settings files. They print out all settings which significantly change between hosts depending on which host I'm simulating.

In summary, I don't think I can help just by looking at the error - other than the obvious error being reported in a settings file - but I would definitely try and simplify the importing. And I do like to print out all the essential settings every time runserver reloads.

Good luck

M



On 20/05/2020 9:59 am, chaitanya orakala wrote:
Thank Jeorge. I went through that blog long back but I can't find a relation to my Error. I will try contacting my manager regarding this. will let you know if I find anything. Have a great day


On Tue, May 19, 2020 at 2:44 PM Jorge Gimeno <jlgimen...@gmail.com <mailto:jlgimen...@gmail.com>> wrote:

    I'm not sure why you're getting an exception.  I know the import
    mechanism in Python 2 was a bit different, so I'm not sure if
    that's the issue or if Django's import mechanism isn't finding
    your settings file.

    I don't know if you have tried this, but I saw a blog post on
    using multiple settings files.  Maybe it will help:
    
https://simpleisbetterthancomplex.com/tips/2017/07/03/django-tip-20-working-with-multiple-settings-modules.html

    I hope this helps!

    -Jorge

    On Mon, May 18, 2020 at 6:51 PM chaitanya orakala
    <chaitu.orak...@gmail.com <mailto:chaitu.orak...@gmail.com>> wrote:

        I tried that way, sir. but it's of no use. I don't know how to
        resolve this issue. its been troubling me for 3 days now

        On Mon, May 18, 2020 at 9:29 PM Mike Dewhirst
        <mi...@dewhirst.com.au <mailto:mi...@dewhirst.com.au>> wrote:

            On 19/05/2020 11:10 am, chaitanya orakala wrote:
            > I am using Python 2.7

            It is possible you need a top line in the file like this ...

            from __future__ import absolute_import

            I haven't been following this thread so someone may have
            mentioned that
            already.


-- You received this message because you are subscribed to
            the Google Groups "Django users" group.
            To unsubscribe from this group and stop receiving emails
            from it, send an email to
            django-users+unsubscr...@googlegroups.com
            <mailto:django-users%2bunsubscr...@googlegroups.com>.
            To view this discussion on the web visit
            
https://groups.google.com/d/msgid/django-users/95afb956-98f8-6664-9107-d0935b75cf6c%40dewhirst.com.au.

-- You received this message because you are subscribed to the
        Google Groups "Django users" group.
        To unsubscribe from this group and stop receiving emails from
        it, send an email to django-users+unsubscr...@googlegroups.com
        <mailto:django-users+unsubscr...@googlegroups.com>.
        To view this discussion on the web visit
        
https://groups.google.com/d/msgid/django-users/CAPcTzRZHgBG1Q90Rk8VmNS%2ByzmQLd1bdq8ZPgA6A%2Bumsx4CGvw%40mail.gmail.com
        
<https://groups.google.com/d/msgid/django-users/CAPcTzRZHgBG1Q90Rk8VmNS%2ByzmQLd1bdq8ZPgA6A%2Bumsx4CGvw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- You received this message because you are subscribed to the Google
    Groups "Django users" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to django-users+unsubscr...@googlegroups.com
    <mailto:django-users+unsubscr...@googlegroups.com>.
    To view this discussion on the web visit
    
https://groups.google.com/d/msgid/django-users/CANfN%3DK9MAMn3WezyhMU5Rrv5DWWFNxQ0jc9RnfyK-qyCOiV%2BeA%40mail.gmail.com
    
<https://groups.google.com/d/msgid/django-users/CANfN%3DK9MAMn3WezyhMU5Rrv5DWWFNxQ0jc9RnfyK-qyCOiV%2BeA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com <mailto:django-users+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAPcTzRaZCKqFZ-smQwNscYtmivyt1_tHhvF94wyN60LVHu4Wvw%40mail.gmail.com <https://groups.google.com/d/msgid/django-users/CAPcTzRaZCKqFZ-smQwNscYtmivyt1_tHhvF94wyN60LVHu4Wvw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2309e2fd-f4ae-01ea-3028-542066d725d6%40dewhirst.com.au.

Reply via email to