#24620 closed Bug (worksforme)
showmigrations broken in Django 1.8
Reported by: | Miguel Araujo | Owned by: | nobody |
---|---|---|---|
Component: | Core (Management commands) | Version: | 1.8 |
Severity: | Normal | Keywords: | showmigrations |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
After upgrading to Django 1.8 and running python manage.py showmigrations
it breaks with the following stack trace:
Traceback (most recent call last): File "manage.py", line 20, in <module> execute_from_command_line(sys.argv) File "/Users/map/.virtualenvs/odin/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line utility.execute() File "/Users/map/.virtualenvs/odin/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/Users/map/.virtualenvs/odin/lib/python2.7/site-packages/django/core/management/base.py", line 390, in run_from_argv self.execute(*args, **cmd_options) File "/Users/map/.virtualenvs/odin/lib/python2.7/site-packages/django/core/management/base.py", line 441, in execute output = self.handle(*args, **options) File "/Users/map/.virtualenvs/odin/lib/python2.7/site-packages/django/core/management/commands/showmigrations.py", line 32, in handle connection = connections[db] File "/Users/map/.virtualenvs/odin/lib/python2.7/site-packages/django/db/utils.py", line 234, in __getitem__ if hasattr(self._connections, alias): TypeError: hasattr(): attribute name must be string
This can be fixed adding use_argparse = True
to show migrations command class, so that add_arguments gets executed settting defaults. This way you get the expected response.
Change History (5)
comment:1 by , 10 years ago
Easy pickings: | unset |
---|---|
Has patch: | unset |
comment:2 by , 10 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:3 by , 10 years ago
Ok,
Seems to be an issue with django-configurations which sets a self.option_list
making use_argparse = True
and then turning the property False and not calling add_arguments
.
Related to this:
https://github.com/jezdez/django-configurations/issues/109
Sorry for the false positive.
Miguel
comment:4 by , 10 years ago
I've been reading some of the commits that moved from optparse to argparse Django's command system:
https://github.com/django/django/commit/856863860352aa1f0288e6c9168a0e423c4f5184
https://github.com/django/django/commit/f17b24e407385eb18651bf023a187347aa9c1f75
To be honest if option_list
has been replaced by add_arguments
method. And in
BaseCommand
add_arguments
is called only for new system as you can see here:
https://github.com/django/django/blob/0ed7d155635da9f79d4dd67e4889087d3673c6da/django/core/management/base.py#L308
This change is in reality backwards incompatible (which is not Django's usual philosophy), although the door stays open for still being backwards compatible, but it implies author's work. In my understanding usually Django gives a time gap to adjust apps in situations like this.
As django-configurations is still using optparse and is injecting an option for all commands, which sets the right configuration to use. It is breaking all Django commands.
comment:5 by , 10 years ago
Seems last commit of django-configurations has this already handled:
https://github.com/jezdez/django-configurations/blob/master/configurations/importer.py#L37
I can't reproduce this using the tutorial project.