makemigrations and language_code

[Hugo Osvaldo Barrera]

I'm having a rather confusing scenario regarding makemigrations and
language_code:

* I've an app (let's call it myapp) which I'm developing.
* myapp relies on the another app (let's call it libapp).
* myapp has language_code set to "es-ar".
* libapp was developed separately, and has been installed via pip.

While developing myapp, whenever I run "makemigrations" a migrations is
also created for libapp. The migrations updates all the verbose_name and
help_text fields and nothing else. I don't want this, especially since
it creates a conflict in the migration graph when I later upgrade
libapp.

How can I have makemigrations *ignore* the language_code?

Also, why does makemigrations create this migration for libapp, but not
an equivalent one for django.contrib.admin?
I tried looking at things like the admin to see how they avoid this, and
found no clues.

Thanks,

--
Hugo Osvaldo Barrera

[Aron Podrigal]

Simply run 

./manage.py makemigrations myapp

That will avoid running for all your installed apps.

[Hugo Osvaldo Barrera]

 

On Tue, Oct 20, 2015, at 10:39, Aron Podrigal wrote:

Simply run 

./manage.py makemigrations myapp

 

That will avoid running for all your installed apps.

 

That's merely a workaround, but it still doesn't solve the problem. Mainly, other users of libapp will still encounter the same issue.

 

I'm curious as to how the admin app avoid this particular issue.

--

Hugo Osvaldo Barrera

 

[Collin Anderson]

Hi,

is libapp using ugettext_lazy? That's what the admin app is using.

Collin