2. Alternatively make migrations on some branch and then make a pull request to add those into main.
For additional context here is [Door Dash talking about django](https://doordash.news/company/tips-for-building-high-quality-django-apps-at-scale/), it's a little outdated given it's from 2017 (the file layout they recommend changing from the tutorial is different in the modern tutorial), but they talk about how it's important to squash migrations, since they are cumulatively built on each other. Since I made a table called ProductsPhotso [sic.], and then deleted it, there is a migration that will be applied in my local branch that won't be applied in other people's if they makemigrations from an empty database without any migrations in their branch.
The Door Dash people actually talked about how they would run into an issue where the migrations would run in production but not in development. They said this was likely a result of having a bunch of cross-app foreign keys creating odd circular dependencies.
I don't really know how we should handle migrations, whether to have people make and then apply them as part of setup as we change and expand the database(s), or to keep them in main - especially since there are some unnecessary ones already (creating and then deleting ProductPhotso [sic.]).
Two possible fixes:
(windows) write a python script to do the same thing
def make_migrations(): cmd = "python web/selecto/manage.py makemigrations" subprocess.run(cmd, shell=True) cmd = "python web/selecto/manage.py migrate" subprocess.run(cmd, shell=True)
if name == 'main': globals()[sys.argv[1]]()