Migrations HUGE error

[letops]

I have a massive error with the migrations and I seriously need some help with this.

When I use this library in another project, every time I make a pip install --upgrade django_openpay all the migrations created locally for django_openpay are destroyed, because there are no migrations files inside the .tar.gz and/or the wheels file.

Now, I cannot publish my local migrations because almost all the models inside this project need to connect to an "unknown" Customer model. I say "unknown" because we have an AbstractCustomer which is meant to be inherited from and used in the project using this library. The Customer concept could be a user, business, team, person, etc; we don't want to marry our AbstractCustomer model to a single concept.

Is there a way to prevent the deletion of the migrations every time the project is upgraded? Or is there a way to create the migrations without marrying the AbstractCustomer model to a single concept?

[letops]

Mezzanine and examples

So, I found this article about "model fields injection" and a simple explanation about how it Mezzanine works. Although this article is old and is based on the rules of Django 1.5, it might be a great resource.

Reverse inheritance

I also thought about something that I will still have to test. Every article talks about inheriting the library's class and modify its fields (just like we are doing here), but we still have the migration problem, BUT what if instead of inheriting the library's class, we make the library class inherit from a project's abstract class?. This is:

You create an abstract model in your project, where you set the extra fields you need, then you set a variable in your settings.py file (let's say CUSTOMER_MODEL) with the name of your model. Django_openpay get your custom model and send it to the actual class Customer model to make a reverse inheritance. In pseudocode we would do:

AbstractCustomerModel = get_external_model(CUSTOMER_MODEL)
class Customer(AbstractOpenpayBase, AbstractCustomerModel):
    # fields

If no CUSTOMER_MODEL is defined, we just send object to be inherited from.

This is just an idea and I cannot test it until January, but if I am correct, this would still require to find a way to prevent the migrations override. (May be maintain them manually and rename them).