django.contrib apps migrations

[Sean McKinley]

Django 1.7+ noob here. Are you supposed to to track the migrations performed within the django.contrib apps? How do you deploy to production on a different machine without grabbing these migrations from the django installation?

[Michal Petrucha]

Hi Sean,

You don't have to do anything special – the packages in django.contrib
ship with their own migrations, which means that once you add some of
them into your INSTALLED_APPS, the next time you run ./manage.py migrate,
the migrations runner will simply pick up those migrations from where
they are, and apply them.

If I may ask, what did you mean by grabbing those migrations? Django
expects each migration to reside inside the package to which it
belongs, so if you take a migration from one of the contrib packages,
and put it somewhere else, it probably won't work correctly, because
it will no longer be inside the respective contrib package.

Cheers,

Michal

[McKinley]

Hi Michal,

I know the django.contrib migrations reside within my virtualenv. What if I wanted a fellow developer to have access to these migrations without sharing the same django install. If i have a colleague working on their own machine and they git pull my django project, they aren't getting my admin and auth migrations so aren't we working on different data afterwards?

[Michal Petrucha]

On Fri, May 13, 2016 at 01:01:22PM -0700, McKinley wrote:
> Hi Michal,
>
> I know the django.contrib migrations reside within my virtualenv. What if I
> wanted a fellow developer to have access to these migrations without
> sharing the same django install. If i have a colleague working on their own
> machine and they git pull my django project, they aren't getting my admin
> and auth migrations so aren't we working on different data afterwards?

If someone else sets up the same project on a different machine, they
will still need to install the same version of Django in their
virtualenv for it to work. That means, they will also install the
necessary contrib pacages and their migrations on their machines,
exactly the same way as if you used any other third-party package that
includes models.

Migrations are a part of thier packages' code base. So the migrations
for django.contrib.admin are part of the code base of
django.contrib.admin, just like migrations for any of your packages
are part of the code base of your packages. There is no reason to
treat them in any special way. When you install Django, which includes
all its contrib packages, you inevitably also install all the
migrations that ship with Django.

Does this help answer your question? (I'm not sure I understand your
concerns correctly, to be honest.)

Michal

[McKinley]

I managed to use fixtures to suit my needs for maintaining concurrency across admin app with collaborators.