Hi Markus,
I don't really think it's the Custom model that's at fault here - this
migration was created months ago. The point is that auth migrations are
stored in, to my mind, the wrong place (in /Users/XXXX/.virtualenvs/YYYY
/lib/python2.7/site-packages/django/contrib/auth/) and a separate problem
revealed this to me. I've included a stack trace below though.
Cheers,
Ed
Running migrations:
Applying
auth.0002_customer_payingcustomer_projectmanager_staff...Traceback (most
recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/__init__.py",
line 385, in execute_from_command_line
utility.execute()
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/__init__.py",
line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/base.py",
line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/base.py",
line 338, in execute
output = self.handle(*args, **options)
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
line 160, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/executor.py",
line 63, in migrate
self.apply_migration(migration, fake=fake)
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/executor.py",
line 91, in apply_migration
if self.detect_soft_applied(migration):
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/executor.py",
line 135, in detect_soft_applied
apps = project_state.render()
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/state.py",
line 67, in render
model.render(self.apps)
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/state.py",
line 311, in render
body,
File
"/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/models/base.py",
line 155, in __new__
raise TypeError("%s cannot proxy the swapped model '%s'." % (name,
base_meta.swapped))
TypeError: PayingCustomer cannot proxy the swapped model
'emailcustomuser.User'.
On Monday, 10 November 2014 09:35:29 UTC+1, Markus Holtermann wrote:
>
> Hey Ed,
>
> you certainly don't have to copy the virtualenv over to production!
>
> Can you share some insights on your custom user model and your settings. A
> complete traceback, if you have any, helps too.
>
> /Markus
>
> On Monday, November 10, 2014 9:00:04 AM UTC+1, Dr Ed wrote:
>>
>>
>>
>> On Sunday, 9 November 2014 14:50:54 UTC+1, Daniel Roseman wrote:
>>>
>>> On Sunday, 9 November 2014 13:40:12 UTC, Dr Ed wrote:
>>>>
>>>> Okay, I'm confused. I found it, in here:
>>>> /Users/XXXX/.virtualenvs/YYYY/lib/python2.7/site-
>>>> packages/django/contrib/auth/migrations
>>>>
>>>> Why are app related migrations being stored in this location?
>>>>
>>>> Cheers,
>>>>
>>>> Ed
>>>>
>>>
>>> What? Migrations related to Django's auth app are, not surprisingly,
>>> stored alongside the code to that app. Why does this puzzle you?
>>>
>>
>> I guess it's because I thought that we could build migrations on the
>> development machines and then update the project on the production machine
>> and apply the migrations. Obviously this assumption was wrong and we need
>> to distribute the entire .virtualenv too...
>>
>> Fine, if that's the way it is, that's the way it is, but to me this seems
>> odd because everything else in there is just something you 'pip install'
>> and I would not expect to mix 'user data' with 'installed packages' like
>> this. It actually seems like an unfortunate design decision since it forces
>> you - unless you try to be clever - to put django etc into the
>> repository... we did this before and shifting to 1.7 was more painful as a
>> result).
>>
>> Anyway, thanks for the reply!
>>
>> Cheers,
>>
>> Ed
>>
>
--
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 post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/e03ee265-a97c-4680-9160-c39417c5885b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
