Django-celery-beat: missing migration in pypi release

[rsichnyi]

1. create clean django2.0 project
2. pip install django-celery-beat
3. add django_celery_beat to installed_apps
4. run python manage.py migrate

Actual result:
the warning appears:

  Your models have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

Expected:
no warnings

The reason is missing migration in pypi release

[DEKHTIARJonathan]

Just execute:

python manage.py makemigrations
python manage.py migrate

[rsichnyi]

@DEKHTIARJonathan it works for development, but i don't feel like changing the code of library in the process of prod deployment...

[DEKHTIARJonathan]

It doesn't feel abnormal for me that you have to perform "makemigrations" in the prod deployment.
To be honest, I don't really know if there is any best practice (well argumented) that in favor or against this practice.

[BITSOLVER]

The problem comes if you run "makemigrations" in production and the same migration appears in an update later on. This will cause "migrate" to fail due to a conflict, if the migration is identical to the one already applied then you could get away with running "--fake" on the updated version.

Personally I think the correct migrations should come from the library and you should not need to run "makemigrations" when using a 3rd party library. A minor update would be really helpful.

[DEKHTIARJonathan]

It seems your explanation to be coherent up to me.
I then agree that the migrations should be included in the package.

[ilhnctn]

Just worked on my project too (Python 3.6, Django==1.11.9, djangorestframework==3.7.7, pip 9.0.1 from /usr/local/lib/python3.6/site-packages)
As @DEKHTIARJonathan stated,

python manage.py makemigrations
python manage.py migrate

[rsichnyi]

Personally I think the correct migrations should come from the library and you should not need to run "makemigrations" when using a 3rd party library. A minor update would be really helpful.

This is what i'm talking about

[mbaechtold]

This issue probably is a duplicate of https://github.com/celery/django-celery-beat/issues/90.

[pwmarcz]

Seconding the request for a release. 1.1.0 is broken (not only a migration file is missing, but it's impossible to provide a correct one yourself due to https://github.com/celery/django-celery-beat/commit/5bccc2dd9f5dd30f19cff30ffcf449c5fca91897) and blocks us from upgrading to Django 2.0.

[muhtarc4n]

Can't we just have a bug release (v1.1.1) for this issue. We enabled migration tests and now they are all failing because of missing migration. We can't just make migration and create migration file in dependency folder. We don't have permission which is very good practice.

[DEKHTIARJonathan]

I support this @thedrow

[muhtarc4n]

And I think fix is already in master branch. I can see 5th migration in migrations folder.

[mbaechtold]

Until there is a new release, you can still pip install the package directly from GitHub. You can even specify a specific commit hash while doing so, no need to install from the master branch:

pip install git+https://github.com/celery/django-celery-beat@ba48402770eead01f059cb364fd522996761d003#egg=django-celery-beat

[DEKHTIARJonathan]

Come on, everything would be so much easier if we could have a minor release. Why would it be a problem to just deploy a small patch.

Additionnally the existing version is not working properly: #113 #117

[muhtarc4n]

@mbaechtold it is impossible to install this dependency this way in our company. We put dependency in requirements file and it pulls version from pypi repository.

There is a bug and project needs bug fix version.

[mbaechtold]

@muhtarc4n, you can install packages from GitHub by specifying them in your requirements.txt too. See the docs of pip, especially the part about Requirements Files:

For example, suppose a dependency, _SomeDependency_ from PyPI has a bug, and you can't wait for an upstream fix. [..]

You might also have a look at the supported forms when installing from Git.

[DEKHTIARJonathan]

I guess what @muhtarc4n say, is that it is not authorized to do such a thing in his company.
Which is, by the way, my situation. Only official versions available through PyPI are authorized.

[Ivo-Donchev]

This was caused by a Solar.event CharField with choices get from an unordered set which causes the new migration every time you run makemigrations. (same choices but different order every time)

It's seems that it's already fixed here:
https://github.com/celery/django-celery-beat/pull/92/files
but it's not released yet

[DEKHTIARJonathan]

Absolutely, but that's a very good reason to release a small patch that fixes the problem.

[Ivo-Donchev]

@mbaechtold Is there a chance for a bugfix release soon :) ?

[mbaechtold]

@Ivo-Donchev, I'm sorry, I do not have the permission for releasing this Python package.

[Ivo-Donchev]

:disappointed: @mbaechtold I suppose specifying requirements' version of this package to the lastest git commit in master is a possible solution then...

Ok, thanks anyway

[mbaechtold]

You could even go further and host your own PyPI server, fork this package and release it on your private PyPI server.

[Ivo-Donchev]

@mbaechtold It's always an option :slightly_smiling_face: but is too much overkill to do it just to avoid an empty migration when running makemigrations :D

[thedrow]

I'll release as soon as I can. Sorry for the delay guys.