hackoregon / team-budget

Repo for the Budget team's backend code
MIT License
6 stars 4 forks source link

ImproperlyConfigured exception when running makemigrations #105

Open MikeTheCanuck opened 7 years ago

MikeTheCanuck commented 7 years ago

I performed a walkthrough of the new README in advance of tomorrow's Hackathon - make sure I know what others will be using, and see if there's any issues that I could clear up.

I discovered one issue that I don't know how to immediately solve, so rather than delay the solution I'm posting my finding in hopes that others might know how to solve.

Steps taken

I'm following this version of the README and I got through to Step 4 of "setting up your development environment". When I run the ./budget_proj/manage.py makemigrations command, I receive this error in return:

./budget_proj/manage.py makemigrations
Traceback (most recent call last):
  File "./budget_proj/manage.py", line 22, in <module>
    execute_from_command_line(sys.argv)
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
    utility.execute()
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/core/management/__init__.py", line 359, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/core/management/__init__.py", line 208, in fetch_command
    klass = load_command_class(app_name, subcommand)
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/core/management/__init__.py", line 40, in load_command_class
    module = import_module('%s.management.commands.%s' % (app_name, name))
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 665, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/core/management/commands/makemigrations.py", line 11, in <module>
    from django.db.migrations.autodetector import MigrationAutodetector
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/db/migrations/autodetector.py", line 13, in <module>
    from django.db.migrations.questioner import MigrationQuestioner
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/db/migrations/questioner.py", line 12, in <module>
    from .loader import MigrationLoader
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/db/migrations/loader.py", line 10, in <module>
    from django.db.migrations.recorder import MigrationRecorder
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/db/migrations/recorder.py", line 12, in <module>
    class MigrationRecorder(object):
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/db/migrations/recorder.py", line 26, in MigrationRecorder
    class Migration(models.Model):
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/db/migrations/recorder.py", line 27, in Migration
    app = models.CharField(max_length=255)
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/db/models/fields/__init__.py", line 1043, in __init__
    super(CharField, self).__init__(*args, **kwargs)
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/db/models/fields/__init__.py", line 166, in __init__
    self.db_tablespace = db_tablespace or settings.DEFAULT_INDEX_TABLESPACE
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/conf/__init__.py", line 53, in __getattr__
    self._setup(name)
  File "/Users/mike/code/~hackoregon/team-budget/budget_venv/lib/python3.5/site-packages/django/conf/__init__.py", line 39, in _setup
    % (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.

Is there a missing step where we'd run source bin/env.sh or similar to populate the DJANGO_SETTINGS_MODULE? Or is this an irreproducible artifact of my ever-shifting dev environment?

jimtyhurst commented 7 years ago

I was not able to reproduce @MikeTheCanuck 's problem. I created a new directory, cloned the repository, and followed the instructions in the top-level README.md. I did not change any of the defaults, so it created a SQLite database in my dev environment. I was able to load data, then get the expected results from endpoints from local ./budget_proj/manage.py runserver. I then changed the values in project_config.py to point to the integration instance of PostgreSQL and started a Docker container through ./budget_proj/bin/start-proj.sh -l. Again, I received expected results from endpoints, including 500 when the response is too big.

I did notice one error with a path in step 2: pip install -r requirements/dev.txt should be: pip install -r budget_proj/requirements/dev.txt I will file a Pull Request with that fix.

You only need source budget_proj/bin/env.sh when building the Dockerfile.

Note: The procedure for configuring is slightly different, so you need to have the latest from master branch.

jimtyhurst commented 7 years ago

What were the contents of budget_proj/budget_proj/project_config.py when you received the error? Were you trying to run a local instance of PostgreSQL? I have not tried that configuration yet, because I had trouble installing PostgreSQL on my workstation.

jimtyhurst commented 7 years ago

I do not have DJANGO_SETTINGS_MODULE defined in my Bash shell environment. However, I see this assignment in budget_proj/manage.py: os.environ.setdefault("DJANGO_SETTINGS_MODULE", "budget_proj.settings.dev") Also, when I run: ./budget_proj/manage.py diffsettings I see that there are some Python or Django settings that are set, including: SETTINGS_MODULE = 'budget_proj.settings.dev' I am not sure how/where those variables get set. They are not Bash shell environment variables. At least some of them come from:

budget_proj/budget_proj/setting/base.py
budget_proj/budget_proj/setting/dev.py
hassanshamim commented 7 years ago

Well, I just freshly broke my python installation today so I can't try recreating this until I put 3.5 back on my computer, but some thoughts:

Mike - makemigrations is not necessary to run to get setup the first time. This command just checks of the state of your django models and the database (as described the migrations) and syncs them up if it detects any differences. migrate actually applies those changes to your database if necessary. Since as developers we are hopefully including the migration files with the project this step should do nothing.

@jimtyhurst I did modify that line in manage.py, but it was originally: os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.py") - I just pointed it to the new settings file - choosing to use 'dev' as the default.

dict.set_default here is just setting the 'DJANGO_SETTINGS_MODULE' to the default value if it's not already set

I think that some of our extensions, like DRF, have default settings they come with but I'm not sure if those default settings are actually set in django.conf.settings or they're stored somewhere within the package's codebase.

All other settings you see should be in 'base' or 'dev'.

EDIT Also, I'm actually comfortable having a bug or two in the setup process as long as we're aware of them and know how to fix. Fixing them would be a good way for a new contributor to familiarize themselves with the codebase/github workflow.