0

I'm using git to version control a Django 1.7 + Django CMS 3.0.6 project.

In the course of building various apps etc I'm ending up with a lot of migration files. The migration files are currently included in my git repo.

Thus far I have been trying to avoid including the virtual env files in my repo directly as it seems rather messy and redundant. Instead I have thus far been including a pip requirements file in the repo and using that to recreate the virtual env when needed.

However, I have recently discovered that choosing to include the migration files in the repo seems to require including all of the virtual env files in the repo as well. I say this because upon deploying my project to a production server and trying to run any of the db commands (syncdb, makemigrations or migrate) via python manage.py I get the error:

KeyError: u"Migration image_gallery.0001_initial dependencies reference nonexistent parent node (u'cms', u'0004_auto_20141108_1256')"

whereas such error does not occur on my local machine, even after deleting the database.

I tracked the source of this error down to the fact that the virtual env on my local machine has a reference to '0004_auto_20141108_1256' (inside the django-cms package - it appears some cms migration info is recorded directly inside the virtual env directory itself) while that of the production environment does not - as the production venv is create thorough a pip requirements file. Therefore, the two virtual envs do not exactly match, even though all third party libs are the same. Currently I am not including the venv in my git repo.

So as I see it I have two options:

1. include the virtual env in my git repo
2. drop the migration files from git

Which option is better and why - or is there a third even better way?

The downside to #1 is unnecessary bloat. The downside to option #2 is one loses the migration history, something one might potentially want to keep.

ferrangb
  • 2,012
  • 2
  • 20
  • 34
David Simic
  • 2,061
  • 2
  • 19
  • 33

2 Answers2

1

You never commit the virtual env, it defeats the purpose; you just add unnecessary content to git.

Instead, freeze the requirements and commit the file:

pip freeze > requirements.txt

Install the packages on the server:

pip install -r requirements.txt
Pran
  • 3,481
  • 2
  • 25
  • 27
  • I am currently following this approach - however, as stated in my question, the resulting virtual env is not identical to my local one, as the migrations performed on my local machine actually modify files in the virtual env itself (inside django-cms, is this specific to django cms?) *in a way not captured by the requirements file*. So when trying to setup a fresh install in production, I am getting errors while trying to setup the db due to this discrepancy in the virtual envs (please see question for more details). – David Simic Dec 28 '14 at 15:51
  • Sorry, should have read twice, and wrote one :). I looked at the project on github and it seemed someone else as similar problem. It seemed there's a fix in v3.0.7. I haven't used django-cms, so I cannot comment if it will solve your problem. https://github.com/divio/django-cms/issues/3572 – Pran Dec 28 '14 at 19:53
  • 1
    Pran: see my answer, hopefully it will help with that issue. The problem in my case is not really a problem with django-cms, but a config issue (though I suspect some of the recommendations I found online for configuring cms might have led to my problem). – David Simic Dec 28 '14 at 23:02
0

The problem is in my django settings.py file:

MIGRATION_MODULES = {
    'cms': 'cms.migrations_django',
    'menus': 'menus.migrations_django',
    'djangocms_file': 'djangocms_file.migrations_django',
    ...
}

I had to introduce the above to get django-cms 3.0.6 to work with django 1.7, a consequence of the fact that migrations in django 1.7 are no longer done with South, as django 1.7 now has it's own migration system, while cms 3.0.6. still expects migrations to be managed by South by default.

However, the effect of the above config is to store migrations in the above described paths which in my case pointed straight to the virtual env. Thus migration info was getting stored within the virtual env dir, leading to problems in deploying to production.

To fix this I modified my project directory structure to include a folder called "migrations":

myproject/manage.py
myproject/migrations/
myproject/myproject/
...

And modified the config to be:

MIGRATION_MODULES = {
    'cms': 'migrations.cms.migrations_django',
    'menus': 'migrations.menus.migrations_django',
    'djangocms_file': 'migrations.djangocms_file.migrations_django',
    ...
}

This has the effect of now storing all migration files in the django project itself (and by extension the git repo). As migration info is no longer in the virtual env directory, there is no longer any reason to consider the rather unattractive possibility of including the virtual env in the repo.

David Simic
  • 2,061
  • 2
  • 19
  • 33