v2.0.2

.ambient-package-update/metadata.py

@@ -24,52 +24,7 @@
     license_year=2023,
     development_status="5 - Production/Stable",
     has_migrations=True,
-    readme_content=ReadmeContent(
-        tagline="""Welcome to **django-migration-zero** - the holistic implementation of "migration zero" pattern for
-Django covering local changes and CI/CD pipeline adjustments.
-
-This package implements the "migration zero" pattern to clean up your local migrations and provides convenient
-management commands to recreate your migration files and updating your migration history on your environments
-(like test or production systems).""",
-        content="""## Features
-
-* Remove all existing local migration files and recreate them as initial migrations
-* Configuration singleton in Django admin to prepare your clean-up deployment
-* Management command for your pipeline to update Django's migration history table to reflect the changed migrations
-
-## Motivation
-
-Working with any proper ORM will result in database changes which are reflected in migration files to update your
-different environment's database structure. These files are versioned in your repository and if you follow any of the
-most popular deployment approaches, they won't be needed when they are deployed on production. This means, they clutter
-your repo, might lead to merge conflicts in the future and will slow down your test setup.
-
-Django's default way of handling this is called "squashing". This approach is covered broadly in the
-[official documentation](https://docs.djangoproject.com/en/dev/topics/migrations/#migration-squashing). The main
-drawback here is, that you have to take care of circular dependencies between models. Depending on your project's
-size, this can take a fair amount of time.
-
-The main benefit of squashing migrations is, that the history stays intact, therefore it can be used for example in
-package which can be installed by anybody and you don't have control over their database.
-
-If you are working on a "regular" application, you have full control over your data(bases) and once everything has
-been applied on the "last" system, typically production, the migrations are obsolete. To avoid spending much time on
-fixing squashed migrations you won't need, you can use the "migration zero" pattern. In a nutshell, this means:
-
-* Delete all your local migration files
-* Recreate initial migration files containing your current model state
-* Fix the migration history on every of your environments""",
-        additional_installation="""* Add this block to your loggers in your main Django `settings.py` to show
-logs in your console.
-
-```python
-"django_migration_zero": {
-    "handlers": ["console"],
-    "level": "INFO",
-    "propagate": True,
-},
-```""",
-    ),
+    readme_content=ReadmeContent(uses_internationalisation=True),
     dependencies=[
         "Django>=3.2",
     ],

.ambient-package-update/templates/snippets/content.tpl

@@ -0,0 +1,28 @@
+## Features
+
+* Remove all existing local migration files and recreate them as initial migrations
+* Configuration singleton in Django admin to prepare your clean-up deployment
+* Management command for your pipeline to update Django's migration history table to reflect the changed migrations
+
+## Motivation
+
+Working with any proper ORM will result in database changes which are reflected in migration files to update your
+different environment's database structure. These files are versioned in your repository and if you follow any of the
+most popular deployment approaches, they won't be needed when they are deployed on production. This means, they clutter
+your repo, might lead to merge conflicts in the future and will slow down your test setup.
+
+Django's default way of handling this is called "squashing". This approach is covered broadly in the
+[official documentation](https://docs.djangoproject.com/en/dev/topics/migrations/#migration-squashing). The main
+drawback here is, that you have to take care of circular dependencies between models. Depending on your project's
+size, this can take a fair amount of time.
+
+The main benefit of squashing migrations is, that the history stays intact, therefore it can be used for example in
+package which can be installed by anybody and you don't have control over their database.
+
+If you are working on a "regular" application, you have full control over your data(bases) and once everything has
+been applied on the "last" system, typically production, the migrations are obsolete. To avoid spending much time on
+fixing squashed migrations you won't need, you can use the "migration zero" pattern. In a nutshell, this means:
+
+* Delete all your local migration files
+* Recreate initial migration files containing your current model state
+* Fix the migration history on every of your environments

.ambient-package-update/templates/snippets/installation.tpl

@@ -0,0 +1,34 @@
+## Installation
+
+- Install the package via pip:
+
+  `pip install {{ package_name|replace("_", "-") }}`
+
+  or via pipenv:
+
+  `pipenv install {{ package_name|replace("_", "-") }}`
+
+- Add module to `INSTALLED_APPS` within the main django `settings.py`:
+
+    ````
+    INSTALLED_APPS = (
+        ...
+        '{{ package_name }}',
+    )
+     ````
+
+{% if has_migrations %}
+- Apply migrations by running:
+
+  `python ./manage.py migrate`
+{% endif %}
+
+- Add this block to your loggers in your main Django `settings.py` to show logs in your console.
+
+```python
+"django_migration_zero": {
+    "handlers": ["console"],
+    "level": "INFO",
+    "propagate": True,
+},
+```

.ambient-package-update/templates/snippets/tagline.tpl

@@ -0,0 +1,6 @@
+Welcome to **django-migration-zero** - the holistic implementation of "migration zero" pattern for
+Django covering local changes and CI/CD pipeline adjustments.
+
+This package implements the "migration zero" pattern to clean up your local migrations and provides convenient
+management commands to recreate your migration files and updating your migration history on your environments
+(like test or production systems).

CHANGES.md

@@ -1,5 +1,8 @@
 # Changelog
 
+* *2.0.2* (2024-06-20)
+  * Internal updates via `ambient-package-update`
+
 * *2.0.1* (2024-06-14)
   * Internal updates via `ambient-package-update`
 

README.md

@@ -17,6 +17,7 @@ management commands to recreate your migration files and updating your migration
 * [Full documentation](https://django-migration-zero.readthedocs.io/en/latest/index.html)
 * Creator & Maintainer: [Ambient Digital](https://ambient.digital/)
 
+
 ## Features
 
 * Remove all existing local migration files and recreate them as initial migrations
@@ -48,7 +49,6 @@ fixing squashed migrations you won't need, you can use the "migration zero" patt
 
 ## Installation
 
-
 - Install the package via pip:
 
   `pip install django-migration-zero`
@@ -72,8 +72,7 @@ fixing squashed migrations you won't need, you can use the "migration zero" patt
   `python ./manage.py migrate`
 
 
-* Add this block to your loggers in your main Django `settings.py` to show
-logs in your console.
+- Add this block to your loggers in your main Django `settings.py` to show logs in your console.
 
 ```python
 "django_migration_zero": {
@@ -83,7 +82,6 @@ logs in your console.
 },
 ```
 
-
 ## Contribute
 
 ### Setup package for development
@@ -199,3 +197,4 @@ being rendered by this updater. It works similar to well-known updaters like `py
 
 To run an update, refer to the [documentation page](https://pypi.org/project/ambient-package-update/)
 of the "ambient-package-update".
+

django_migration_zero/__init__.py

@@ -3,4 +3,4 @@
 Holistic implementation of "migration zero" pattern for Django covering local changes and in-production database adjustments.
 """
 
-__version__ = "2.0.1"
+__version__ = "2.0.2"

pyproject.toml

@@ -48,7 +48,7 @@ dev = [
    'm2r2==0.3.3.post2',
    'mistune<2.0.0',
    'flit~=3.9',
-   'ambient-package-update~=24.6.1',
+   'ambient-package-update~=24.6.3',
    'unittest-parametrize~=1.3',
 ]