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 [email protected].
To post to this group, send email to [email protected].
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.
