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 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/6aaea6b8-d0de-4865-9689-ba48fbf59c65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
