Hello,
Just checking, do you have AUTH_USER_MODULE = 'emailcustomuser.User'?
Did you mark emailcustomuser.User as "swappable" by chance? (I don't think
you want to do that)
Thanks,
Collin
On Monday, November 10, 2014 5:43:23 AM UTC-5, Dr Ed wrote:
>
> 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/6aaea6b8-d0de-4865-9689-ba48fbf59c65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
