Correct special op indentation

.gitlab-ci.yml

@@ -0,0 +1,25 @@
+variables:
+  PDM_PYPI_URL: https://gitlab.gitguardian.ovh/api/v4/projects/435/packages/pypi/simple
+  PDM_PYPI_USERNAME: $PYPI_USERNAME
+  PDM_PYPI_PASSWORD: $PYPI_PASSWORD
+
+stages:
+  - tests
+  - release
+
+workflow:
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+    - if: $CI_COMMIT_TAG
+    - if: $CI_COMMIT_BRANCH == "main"
+    - when: never # no pipeline on feature branch pushes, only MRs
+
+publish:
+  image: 513715405986.dkr.ecr.us-west-2.amazonaws.com/basics/python:3.11-slim-bullseye
+  stage: release
+  only:
+    - tags
+  script:
+    - pip install twine build
+    - python -m build
+    - twine upload --verbose --repository-url https://gitlab.gitguardian.ovh/api/v4/projects/435/packages/pypi/ --username ${PYPI_USERNAME}  --password ${PYPI_PASSWORD} dist/*

LICENSE

@@ -187,6 +187,7 @@
       identification within third-party archives.
 
    Copyright 2019 3YOURMIND GmbH
+   Copyright 2024 GitGuardian
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

README.md

@@ -1,13 +1,13 @@
 # django-replace-migrations
 
-This package is an extension to djangos `makemigrations.py`.
-It can be used to get rid of old migrations as an alternative to djangos `squashmigration` command.
+This package offers a new django command: `replace_all_migrations`.
+It can be use to get rid of old migrations as an alternative to django's `squashmigration` command.
 
 ## Reasoning
 
 In big django projects, migration files easily pile up and get an increasing problem.
-Django comes with the squashmigration command - however, it is hard to handle because of multiple reasons.
-Especially, it can not handle circular dependencies - they must be resolved [manually and with great care](https://stackoverflow.com/questions/37711402/circular-dependency-when-squashing-django-migrations).
+
+Django comes with the squashmigration command - however, it is hard to handle because of multiple reasons. Especially, it can not handle circular dependencies - they must be resolved [manually and with great care](https://stackoverflow.com/questions/37711402/circular-dependency-when-squashing-django-migrations).
 
 One possible solution is to:
 
@@ -17,13 +17,11 @@ One possible solution is to:
 
 This workflow might work fine, if you have only few (production) servers - however, it becomes hard, when you have many environments with different versions of your application.
 
-With django-replace-migrations also creates new initial migrations, but also, additionally, adds the already existing migrations to the `replace` list of the new migration
-(That list is used by `squashmigrations` as well). By doing that, faking migrations is not needed anymore.
+django-replace-migrations also creates new initial migrations, but also, additionally, it adds the already existing migrations to the `replace` list of the new migration (That list is used by `squashmigrations` as well). By doing that, faking migrations is not needed anymore.
 
 ## Warning
 
-The new replacing migrations will not consider any `RunPython` or `RunSQL` operations.
-That might be acceptable depending on your use of those operations and if you need those to prepare a fresh database.
+The new replacing migrations will add not elidable special operations (`RunPython`, `RunSQL` or `SeparateDatabaseAndState`) at the end of the squash files. You will have to manually add them when suitable.
 
 ## Installation
 
@@ -35,17 +33,23 @@ Run
 pip install django-replace-migrations
 ```
 
-and add `django_replace_migrations` to your list of installed apps.
+and add `gg_django_replace_migrations` to your list of installed apps.
 
 ## Simple Workflow
 
-If your apps are not depending on each other, you can use django-replace-migrations like this:
+If your apps are not depending on each other, you can use gg-django-replace-migrations like this:
 
 ```
-./manage.py makemigratons --replace-all --name replace [app1, app2, ...]
+./manage.py replace_all_migrations --name replace [app1, app2, ...]
+```
+
+Note, that you will need to list all of your apps explicitly - otherwise django will also try to replace migrations from dependencies:
+
+```
+from django.apps import apps
+print(" ".join(map(str, sorted({model._meta.app_label for model in apps.get_models()}))))
 ```
 
-Note, that you will need to [list all of your apps](https://stackoverflow.com/questions/4111244/get-a-list-of-all-installed-applications-in-django-and-their-attributes) explicitly - otherwise django will also try to replace migrations from dependencies.
 While `--name` could be omitted, it is highly recommended to use it so that you can easily recognize the new migrations.
 
 If for any of your apps there are not one but two or more migrations created, your apps are depending on each other (see below).
@@ -71,7 +75,7 @@ The workflow for this would be:
 - `git checkout 2.0`
 - create a new branch `git checkout -b 2-0-replace-migrations`
 - Install `django-replace-migration` here.
-- run `./manage.py makemigrations --replace-all --name replace_2_0 app1, app2, ...` ([How to get all apps](https://stackoverflow.com/questions/4111244/get-a-list-of-all-installed-applications-in-django-and-their-attributes))
+- run `./manage.py replace_all_migrations --name replace_2_0 app1, app2, ...` ([How to get all apps](https://stackoverflow.com/questions/4111244/get-a-list-of-all-installed-applications-in-django-and-their-attributes))
 - commit and note the commit hash
 - `git checkout [your main/feature branch]`
 - `git cherry-pick [commit-hash from 2-0-delete-migrations]`
@@ -87,7 +91,3 @@ If your app is below 2.0 and you want to update to something after 2.0, you firs
 - upgrading from 1.0 to 1.5 will be possible
 - upgrading from 2.0 to 3.0 will be possible
 - upgrading from 1.0 to 3.0 will be **not** possible
-
-## `makemigration.py` compatibility
-
-This package requires deep integration into `makemigrations.py` so that I needed to copy the whole `makemigrations.py` here. Currently the version of `makemigrations.py` is copied from Django 2.1, however it is also tested with Django 3.0 and works there as well. If you encounter problems, please write what version of Django you are using.