I'm trying to follow the documentation in https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/operations/ to create a migration which will essentially perform the SQL statement CREATE EXTENSION IF NOT EXISTS hstore; on the database. I've tried adding the following file, called create_extension_hstore.py, to the migrations directory:
from django.db import migrations
from django.contrib.postgres.operations import CreateExtension
class Migration(migrations.Migration):
operations = [CreateExtension(name='hstore')]
My 'mental model' of this is that since Django infer the order of the migrations from their dependencies and this one has none, it should be run first. However, I'm getting the error when I try to run python manage.py makemigrations --merge:
(venv) Kurts-MacBook-Pro:lucy-web kurtpeek$ python manage.py makemigrations --merge
(0.000) SELECT typarray FROM pg_type WHERE typname = 'citext'; args=None
(0.003)
SELECT c.relname, c.relkind
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'v')
AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
AND pg_catalog.pg_table_is_visible(c.oid); args=None
(0.001) SELECT "django_migrations"."app", "django_migrations"."name" FROM "django_migrations"; args=()
Traceback (most recent call last):
File "manage.py", line 29, in <module>
execute_from_command_line(sys.argv)
File "/Users/kurtpeek/Documents/Dev/lucy/lucy-web/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
utility.execute()
File "/Users/kurtpeek/Documents/Dev/lucy/lucy-web/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 356, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/kurtpeek/Documents/Dev/lucy/lucy-web/venv/lib/python3.6/site-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/Users/kurtpeek/Documents/Dev/lucy/lucy-web/venv/lib/python3.6/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/Users/kurtpeek/Documents/Dev/lucy/lucy-web/venv/lib/python3.6/site-packages/django/core/management/commands/makemigrations.py", line 142, in handle
return self.handle_merge(loader, conflicts)
File "/Users/kurtpeek/Documents/Dev/lucy/lucy-web/venv/lib/python3.6/site-packages/django/core/management/commands/makemigrations.py", line 272, in handle_merge
raise ValueError("Could not find common ancestor of %s" % migration_names)
ValueError: Could not find common ancestor of {'0091_family_adopting_or_surrogate', 'create_extension_hstore'}
How can I fix this? I could try adding dependencies=['0001_initial'] to the Migration class but this seems a bit arbitrary as what I actually want is to run this migration before anything else.
I think you would want to add this migration to the dependencies in 0001, if you want it run before the first generated migrations.
If you are just getting to needing hstore now and don't need it to run first you can pretty easily just add as a data migration in place like normal.
I ended up solving the larger problem, using the HStoreField without having to manually run CREATE EXTENSION hstore; on the database, by adding the HStoreExtension() operation to the operations of the 0001_initial.py migration; see also https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/operations/#create-postgresql-extensions.
Related
so my django project was working completely fine and everything worked.
I wanted to rename an app something else so I did and updated all the associated files in including the app.py config file.
I also cleared the database and removed all migration files from each app.
Ever since then I have never been able to finish makemigrations onto my apps.
I even recreated the app I renamed, by doing django-admin startapp "appname" and then copied the contents of models.py admin.py, etc over to see if I somehow cause an internal issue but I just can't figure out what's going on?.
I did manage to get all the makemigrations to success for all apps including the one I remade when I removed this (below) from another apps admin.py file
# accounts/admin.py
class SigBotSettingsInLine(admin.StackedInline):
model = SigBotSettings
#admin.register(Bot)
class BotAdmin(admin.ModelAdmin,):
...
inlines = [SigBotSettingsInLine]
but in the end the python manage.py migrate, still Failed. If someone would help it would be highly appreciated.
Here is the error-code:
(dguacENV) PS C:\Users\Admin\Desktop\djangoProjects\dguac> python manage.py makemigrations accounts
Traceback (most recent call last):
File "manage.py", line 22, in <module>
main()
File "manage.py", line 18, in main
execute_from_command_line(sys.argv)
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\core\management\__init__.py", line 419, in execute_from_command_line
utility.execute()
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\core\management\__init__.py", line 413, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\core\management\base.py", line 354, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\core\management\base.py", line 398, in execute
output = self.handle(*args, **options)
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\core\management\base.py", line 89, in wrapped
res = handle_func(*args, **kwargs)
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\core\management\commands\makemigrations.py", line 88, in handle
loader = MigrationLoader(None, ignore_no_migrations=True)
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\db\migrations\loader.py", line 53, in __init__
self.build_graph()
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\db\migrations\loader.py", line 286, in build_graph
self.graph.ensure_not_cyclic()
File "C:\Users\Admin\anaconda3\envs\dguacENV\lib\site-packages\django\db\migrations\graph.py", line 274, in ensure_not_cyclic
raise CircularDependencyError(", ".join("%s.%s" % n for n in cycle))
django.db.migrations.exceptions.CircularDependencyError: accounts.0001_initial, accounts.0002_auto_20210809_1814, signals.0001_initial
Dependencies in accounts/migrations/0001_initial.py
dependencies = [
('signals', '__first__'),
('auth', '0012_alter_user_first_name_max_length'),
]
Dependencies in accounts/migraitons/0002_auto_20210809_1910.py
dependencies = [
('accounts', '0001_initial'),
]
Dependencies in signals/migrations/0001_initial.py
dependencies = [
('accounts', '0002_auto_20210809_1910'),
]
Dependencies in accounts/migrations/0001_initial.py
dependencies = [
('signals', '__first__'),
('auth', '0012_alter_user_first_name_max_length'),
]
Dependencies in accounts/migraitons/0002_auto_20210809_1910.py
dependencies = [
('accounts', '0001_initial'),
]
Dependencies in signals/migrations/0001_initial.py
dependencies = [
('accounts', '0002_auto_20210809_1910'),
]
This tells us the following:
accounts.0001.initial depends on signals.0001_initial (specified by '__first__'.
accounts.0002_auto_20210809_1910 depends on accounts.0001.initial
signals.0001_initial.py depends on accounts.0002_auto_20210809_1910
The circularity should be clear.
You can either edit these dependencies manually or delete all migrations and generate them again with ./manage.py makemigrations This should solve the problem unless there are underlying issues with the model dependencies themselves.
WARNING
Be very careful when editing or deleting migrations. If your project is deployed to a live server, editing migrations that have already applied will at best do nothing and at worst completely wreck your production database. The proceeding suggestion should only be used if you are working on a project that has not yet been deployed.
SOLVED:
So yes thank you a lot for pointing out about the migration dependency issue, reading that link made me clearly understand how the makemigrations function works.
So after I looked through my dependencies, I found that in my Signals.models file there was a foriegnkey that linked to the Signals app before it was migrated.
I commented out this foreignkey line then migrated and everything worked perfectly.
I even added the foreignkey back afterwards and updated the migration which also worked because at this point the signal database had already been migrated.
I know this is bad practice though and will he changing the way that foreignkey is linked through another method.
Appreciate the help.
I am reorganizing one of my projects to be more re-usable and just generally structured better and am now getting the error below whenever I run makemigrations - I've spent half the day trying to figure this out on my own but have run out of Google results on searches and am in need of some assistance. What I've done was remove a custom user model I had setup so I can use Django's built-in User model and I also namespaced my apps urls. I don't want to include a bunch of code yet that will do nothing but dirty up this post as I am hoping the Traceback has clues that I am not seeing. If you are looking at this and have an idea of what could be the culprit for the error, can you please advice on what you need to see to offer assistance? Thank you.
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
utility.execute()
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/core/management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/core/management/commands/makemigrations.py", line 132, in handle
migration_name=self.migration_name,
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/migrations/autodetector.py", line 45, in changes
changes = self._detect_changes(convert_apps, graph)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/migrations/autodetector.py", line 128, in _detect_changes
self.old_apps = self.from_state.concrete_apps
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/migrations/state.py", line 166, in concrete_apps
self.apps = StateApps(self.real_apps, self.models, ignore_swappable=True)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/migrations/state.py", line 228, in __init__
self.render_multiple(list(models.values()) + self.real_models)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/migrations/state.py", line 296, in render_multiple
model.render(self)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/migrations/state.py", line 585, in render
body,
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/models/base.py", line 158, in __new__
new_class.add_to_class(obj_name, obj)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/models/base.py", line 299, in add_to_class
value.contribute_to_class(cls, name)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/models/fields/related.py", line 707, in contribute_to_class
super(ForeignObject, self).contribute_to_class(cls, name, virtual_only=virtual_only)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/models/fields/related.py", line 307, in contribute_to_class
lazy_related_operation(resolve_related_class, cls, self.remote_field.model, field=self)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/models/fields/related.py", line 84, in lazy_related_operation
return apps.lazy_model_operation(partial(function, **kwargs), *model_keys)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/models/fields/related.py", line 82, in <genexpr>
model_keys = (make_model_tuple(m) for m in models)
File "/Users/rooster/.virtualenvs/ddm_dev/lib/python3.5/site-packages/django/db/models/utils.py", line 13, in make_model_tuple
app_label, model_name = model.split(".")
ValueError: too many values to unpack (expected 2)
This error would only occur if split() returns more than 2 elements:
app_label, model_name = model.split(".")
ValueError: too many values to unpack (expected 2)
This means that either app_label or model_name has a dot (.) in it. My money is on the former as model names are automatically generated
This issue also occurs if you use the refactor tool in Pycharm and accidentally rename a model's name for the entire project instead of for a single file. This effects the migration files as well, and as a result, the makemigrations command doesn't know what to do and throws the Value error.
I fixed it by going into all of the migration files and renaming these lines:
field=models.ForeignKey(default=1, null=True, on_delete=django.db.models.deletion.CASCADE, to='books.models.Topic'),
to:
field=models.ForeignKey(default=1, null=True, on_delete=django.db.models.deletion.CASCADE, to='books.Topic'),
This also happens when you refer another model in your model definition from another app in incorrect way.
Check this bug report - https://code.djangoproject.com/ticket/24547
path should be of the form 'myapp.MyModel' and should NOT include the name of module containing models (which is usually 'models').
The bug is in the state worksforme, and mostly will not be taken up for fixing.
choices expected 2 arguments. if it is more or less then 2 you get this error.
all_choices = (('pick1', 'value1' ), ('pick2', 'value2'), ('pick3', 'value3'))
You haven't provided the tuple for us to debug. However, it's worth knowing that tuples containing single item require a trailing comma.
all_choices = (('pick1', 'value1' ),)
Its a common mistake and it leads to the error
ValueError: too many values to unpack (expected 2)
I have managed to run a simple script located in a 'scripts' folder using 'runscript' from django-extensions. The technique is described here [1] (https://django-extensions.readthedocs.org/en/latest/runscript.html).
The script will run successfully as follows:
python manage.py runscript mysimplescript --script-args Testing 123
Should I now move the script to a sub-folder, then it appears I need to specify the full path to the sub-folder:
python manage.py runscript scripts.myfolder.mysimplescript --script-args Testing 123
I have written a python script which runs successfully when called directly from the command line within its own project folder. The complex script uses a number of additional scripts located within a plethora of sub-folders.
I now want to call this script within django using django-extensions' 'runscript', which means it's being invoked from the 'mysite/' folder where 'manage.py' is located. The script 'mycomplexscript.py' is not in the 'scripts/' folder but relocated to a separate 'myapps/' project folder, along with the sub-folders and scripts.
I've shown the structure below that includes 'mysite/' and some of the sub-folders/files within 'myapp/', notably the module 'myapp/common/types_':
mysite/
manage.py
mysite/
__init__.py
settings.py
urls.py
wsgi.py
scripts
__init__.py
mysimplescript.py
myapps/
__init__.py
mycomplexscript.py
common/
__init__.py
comparison.py
serialisation/
__init__.py
serialisation.py
xml.py
types_/
__init__.py
enum.py
Django-extensions requires that 'mycomplexscript.py' must incorporate a 'run()' function. Line #6 imports a class from one of the project sub-folders:
def run(*script_args):
import os
import sys
import time
from common.serialisation import XML
When calling the script, the error occurs because the module 'common.types_' cannot be located.
python manage.py runscript myapps.mycomplexscript --script-args Testing 123
/usr/lib/python2.7/site-packages/Django-1.9.2-py2.7.egg/django/core/
management/base.py:265: RemovedInDjango110Warning: OptionParser usage for
Django management commands is deprecated, use ArgumentParser instead
RemovedInDjango110Warning)
Exception while running run() in 'myapps.mycomplexscript'
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib/python2.7/site-packages/Django-1.9.2-py2.7.egg/django/core/
management/__init__.py", line 353, in execute_from_command_line
utility.execute()
File "/usr/lib/python2.7/site-packages/Django-1.9.2-py2.7.egg/django/core/
management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.7/site-packages/django_extensions-1.6.1-py2.7.egg/
django_extensions/management/email_notifications.py", line 63, in
run_from_argv
super(EmailNotificationCommand, self).run_from_argv(argv)
File "/usr/lib/python2.7/site-packages/Django-1.9.2-py2.7.egg/django/core/
management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/lib/python2.7/site-packages/django_extensions-1.6.1-py2.7.egg/
django_extensions/management/email_notifications.py", line 75, in execute
super(EmailNotificationCommand, self).execute(*args, **options)
File "/usr/lib/python2.7/site-packages/Django-1.9.2-py2.7.egg/django/core/
management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/usr/lib/python2.7/site-packages/django_extensions-1.6.1-py2.7.egg/
django_extensions/management/utils.py", line 57, in inner
ret = func(self, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/django_extensions-1.6.1-py2.7.egg/
django_extensions/management/commands/runscript.py", line 172, in handle
run_script(mod, *script_args)
File "/usr/lib/python2.7/site-packages/django_extensions-1.6.1-py2.7.egg/
django_extensions/management/commands/runscript.py", line 79, in run_script
mod.run(*script_args)
File "/usr/tester/SwFact/isg_cid-system_test_current/my_site/myapps/
mycomplexscript.py", line 9, in run
from myapps.common.serialisation import XML
File "/usr/tester/SwFact/isg_cid- system_test_current/my_site/myapps/
common/__init__.py", line 7, in <module>
from comparison import Comparison
File "/usr/tester/SwFact/isg_cid-system_test_current/my_site/myapps/
common/comparison.py", line 7, in <module>
from common.types_ import Enum
ImportError: No module named common.types_
The problematic Line #7 in 'comparison.py' is as follows:
from common.types_ import Enum
The error can be fixed if the full path to the root of the project is stated explicitly (+++):
from apps.common.types_ import Enum
This means that I would have to edit all the files and change the paths accordingly, which I'd like to avoid, if possible.
This link [2]:(Python: Referencing another project) describes the referencing another project from the command line, so I realize that this may nothing to do with the fact that I'm trying to do this by using django-extensions' 'runscript'.
Is there a way that I can resolve the path discrepancy, without having to modify all the files? Would setting PYTHONPATH be the answer, as suggested here [3]:(How to use PYTHONPATH)? I checked but 'echo $PYTHONPATH' currently doesn't return anything.
Apologies for the long-winded description.
Thanks in advance.
I tried sys.path.append("my/path") as recommended by link above and [4]:(Python sys.path - appending PYTHONPATH) and it seemed to work, so all the paths included in 'from' are now recognized without having to set the full path, as I described previously here (+++).
myapps/mycomplexscript:
# Procedures
def run(*script_args):
import os
import sys
import time
sys.path.append('/usr/tester/SwFact/isg_cid-system_test_current/
my_site/myapps')
from common.serialisation import XML
from common.task import Subscriber
from test_ import TestHost
from common.filesystem import Directory, File
from common.tables import Column, Condition, CSVTable, Group
from string import Template
from datetime import date, time, datetime, timedelta
from operator import itemgetter
print script_args
So the result when running the script from 'mysite/':
python manage.py runscript myapps.mycomplexscript --script-args Testing 123
/usr/lib/python2.7/site-packages/Django-1.9.2-py2.7.egg/django/core/
management/base.py:265: RemovedInDjango110Warning: OptionParser usage for
Django management commands is deprecated, use ArgumentParser instead
RemovedInDjango110Warning)
('Testing', '123')
It's not ideal to have to hard-code the path this inside the script, so perhaps it can be passed in as one of the arguments. The only problem with this is that imports appear at the top of the file, before any of the command line arguments are processed within the complex script however at least I know it works in principle.
Traceback:
./manage.py test my_app
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/zuber/projects/private-CR/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/home/zuber/projects/private-CR/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/zuber/projects/private-CR/env/local/lib/python2.7/site-packages/django/core/management/commands/test.py", line 30, in run_from_argv
super(Command, self).run_from_argv(argv)
File "/home/zuber/projects/private-CR/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 381, in run_from_argv
parser = self.create_parser(argv[0], argv[1])
File "/home/zuber/projects/private-CR/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 354, in create_parser
self.add_arguments(parser)
File "/home/zuber/projects/private-CR/env/local/lib/python2.7/site-packages/django/core/management/commands/test.py", line 52, in add_arguments
test_runner_class = get_runner(settings, self.test_runner)
File "/home/zuber/projects/private-CR/env/local/lib/python2.7/site-packages/django/test/utils.py", line 152, in get_runner
test_module = __import__(test_module_name, {}, {}, force_str(test_path[-1]))
ImportError: No module named simple
I tried to remove init.py from app folder and then I've got "No module named app_name". When I removed init.py from project folder - console said "No module named settings". How to test my app?
So first of all, you need to put your two __init__.pys back where you found them. They are what allow you to import things from that module. Secondly, you should post the code in manage.py so we have a better idea of what is going on, but it looks to me like you had a line in there that looks something like import django.contrib.admin.util or import <something> from django.contrib.admin.util. This module was removed in the release of django that you're using, so you should replace any occurrances of django.contrib.admin.util with django.contrib.admin.utils.
I resolved the problem by removing
TEST_RUNNER = 'django.test.simple.DjangoTestSuiteRunner'
from settings.py
see related question running all tests post django 1.6
For me while using Pycharm the problem was that the PyCharm test runner was not compatible with Django 2.0
The solution was:
replace line 254:EOF with
if VERSION[1] > 1 or VERSION[0] > 1:
return DjangoTeamcityTestRunner(**options).run_tests(test_labels,
extra_tests=extra_tests, **options)
return run_the_old_way(extra_tests, options, test_labels, verbosity)
Instead of:
if VERSION[1] > 1:
return DjangoTeamcityTestRunner(**options).run_tests(test_labels,
extra_tests=extra_tests, **options)
return run_the_old_way(extra_tests, options, test_labels, verbosity)
I'm developing django based site on a windows machine, but I git push my changes to a headless Ubuntu server for staging purposes. When I git pull the changes into the working directory on the staging server I then need to run manage.py collectstatic. However, when I do this the change monitor ('Monitoring Code Changes' section of Reloading Source Code) reports that it has detected changed files:
monitor (pid=26216): Starting change monitor.
You have requested to collect static files at the destination
location as specified in your settings.
This will overwrite existing files!
Are you sure you want to do this?
Type 'yes' to continue, or 'no' to cancel: monitor (pid=26216): Change detected to 'myproject/manage.py'.
monitor (pid=26216): Triggering process restart.
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/envs/myproject/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 453, in execute_from_command_line
utility.execute()
File "/envs/myproject/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/envs/myproject/local/lib/python2.7/site-packages/django/core/management/base.py", line 222, in run_from_argv
self.execute(*args, **options.__dict__)
File "/envs/myproject/local/lib/python2.7/site-packages/django/core/management/base.py", line 255, in execute
output = self.handle(*args, **options)
File "/envs/myproject/local/lib/python2.7/site-packages/django/core/management/base.py", line 385, in handle
return self.handle_noargs(**options)
File "/envs/myproject/local/lib/python2.7/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py", line 160, in handle_noargs
% (destination_display, clear_display))
KeyboardInterrupt
I ran 'touch myproject/wsgi.py' to 'update the change cache' and then ran the collectstatic command again. This resulted in the same error.
I then entered the python console and ran the monitor starting command manually:
import myproject.monitor
myproject.monitor.start(1)
This made no difference. I also tried adding a conditional to the monitor so that it would ignore manage.py when checking for file changes but this just gave me the same error with myproject/__init__.py being the file it reported as having changed. DOes anyone know what is causing this?
I've worked out what was causing this. The legacy file modification times are held in a dictionary as unix timestamps with decimal places (e.g. 1366283624.92) while the actual modification times are returned by os.stat(path).st_mtime as integers. All I had to do was edit the monitor script at line 54, changing:
if mtime != _times[path]:
to
if int(mtime) != int(_times[path]):
I just hope this doesn't lead to any further problems down the road