Summary

Add utilities for fetching dependencies for an evolution or its app.

Review Request #11228 — Created Oct. 18, 2020 and submitted Oct. 30, 2020, 3:28 p.m.

Information

Owner

chipx86

Repository

Django Evolution

Branch

master

Bugs

Depends On

Reviewers

Groups

django-evolution

People

Description

BEFORE_EVOLUTIONS
BEFORE_MIGRATIONS
AFTER_EVOLUTIONS
AFTER_MIGRATIONS

Each is a list of items, where each item is either a string containing
an app label (for evolutions) or a tuple containing an app label and
evolution/migration name (for evolutions and migrations).

This change begins adding support for this by introducing utility
functions that will look up these dependencies.
get_evolution_app_dependencies() will fetch the dependencies specified
at the top-level evolutions/__init__.py for an app, and
get_evolution_dependencies() will fetch those defined in a particular
evolution.

Along with checking an evolution's specified dependencies,
get_evolution_dependencies() will also check if any mutations have
dependencies to inject. This is a new feature of mutations.

Currently only MoveToDjangoMigrations implements mutation-defined
dependencies, and ensures that the evolution will apply after the
migrations it applies to. This ensures that for a new database (or new
app), the migrations will always apply first (since the intent is to
ultimately have the app use them instead of evolutions). For an existing
app, the evolver will already make sure those migrations are marked as
applied by scanning ahead for this mutation, and it's important that the
evolution doesn't try to apply before this step happens.

Upcoming changes will factor the dependencies in when determining the
order in which migrations and evolutions will apply.

Testing Done

Unit tests pass.

Made use of this with upcoming changes to implement full dependency
support.

Commits

Summary	ID
Add utilities for fetching dependencies for an evolution or its app. Django Evolution 2.1 is getting support for dependencies defined in evolutions, allowing a single evolution or all evolutions for an app to apply before or after other evolutions or migrations. These can be specified as an app-level dependency (in the `evolutions/__init__.py`) or an evolution-level dependency by setting the following: * `BEFORE_EVOLUTIONS` * `BEFORE_MIGRATIONS` * `AFTER_EVOLUTIONS` * `AFTER_MIGRATIONS` Each is a list of items, where each item is either a string containing an app label (for evolutions) or a tuple containing an app label and evolution/migration name (for evolutions and migrations). This change begins adding support for this by introducing utility functions that will look up these dependencies. `get_evolution_app_dependencies()` will fetch the dependencies specified at the top-level `evolutions/__init__.py` for an app, and `get_evolution_dependencies()` will fetch those defined in a particular evolution. Along with checking an evolution's specified dependencies, `get_evolution_dependencies()` will also check if any mutations have dependencies to inject. This is a new feature of mutations. Currently only `MoveToDjangoMigrations` implements mutation-defined dependencies, and ensures that the evolution will apply after the migrations it applies to. This ensures that for a new database (or new app), the migrations will always apply first (since the intent is to ultimately have the app use them instead of evolutions). For an existing app, the evolver will already make sure those migrations are marked as applied by scanning ahead for this mutation, and it's important that the evolution doesn't try to apply before this step happens. Upcoming changes will factor the dependencies in when determining the order in which migrations and evolutions will apply.	deb683e014dad3af505f66af8692ea603f522e3f

Summary

Add utilities for fetching dependencies for an evolution or its app.

Django Evolution 2.1 is getting support for dependencies defined in evolutions, allowing a single evolution or all evolutions for an app to apply before or after other evolutions or migrations. These can be specified as an app-level dependency (in the `evolutions/__init__.py`) or an evolution-level dependency by setting the following: * `BEFORE_EVOLUTIONS` * `BEFORE_MIGRATIONS` * `AFTER_EVOLUTIONS` * `AFTER_MIGRATIONS` Each is a list of items, where each item is either a string containing an app label (for evolutions) or a tuple containing an app label and evolution/migration name (for evolutions and migrations). This change begins adding support for this by introducing utility functions that will look up these dependencies. `get_evolution_app_dependencies()` will fetch the dependencies specified at the top-level `evolutions/__init__.py` for an app, and `get_evolution_dependencies()` will fetch those defined in a particular evolution. Along with checking an evolution's specified dependencies, `get_evolution_dependencies()` will also check if any mutations have dependencies to inject. This is a new feature of mutations. Currently only `MoveToDjangoMigrations` implements mutation-defined dependencies, and ensures that the evolution will apply after the migrations it applies to. This ensures that for a new database (or new app), the migrations will always apply first (since the intent is to ultimately have the app use them instead of evolutions). For an existing app, the evolver will already make sure those migrations are marked as applied by scanning ahead for this mutation, and it's important that the evolution doesn't try to apply before this step happens. Upcoming changes will factor the dependencies in when determining the order in which migrations and evolutions will apply.

deb683e014dad3af505f66af8692ea603f522e3f

flake8 passed.

JSHint passed.

Change Summary:

Folded changes for mutation-defined dependencies into this change.

Description:

		Django Evolution 2.1 is getting support for dependencies defined in
		evolutions, allowing a single evolution or all evolutions for an app to
		apply before or after other evolutions or migrations. These can be
		specified as an app-level dependency (in the `evolutions/__init__.py`)
		or an evolution-level dependency by setting the following:

		`BEFORE_EVOLUTIONS`
		`BEFORE_MIGRATIONS`
		`AFTER_EVOLUTIONS`
		`AFTER_MIGRATIONS`

		Each is a list of items, where each item is either a string containing
		an app label or a tuple containing an app label and evolution/migration
		name.

		This change begins adding support for this by introducing utility
		functions that will look up these dependencies.
		`get_evolution_app_dependencies()` will fetch the dependencies specified
		at the top-level `evolutions/__init__.py` for an app, and
		`get_evolution_dependencies()` will fetch those defined in a particular
		evolution.

	+	Along with checking an evolution's specified dependencies,
	+	`get_evolution_dependencies()` will also check if any mutations have
	+	dependencies to inject. This is a new feature of mutations.
	+
	+	Currently only `MoveToDjangoMigrations` implements mutation-defined
	+	dependencies, and ensures that the evolution will apply after the
	+	migrations it applies to. This ensures that for a new database (or new
	+	app), the migrations will always apply first (since the intent is to
	+	ultimately have the app use them instead of evolutions). For an existing
	+	app, the evolver will already make sure those migrations are marked as
	+	applied by scanning ahead for this mutation, and it's important that the
	+	evolution doesn't try to apply before this step happens.
	+
		Upcoming changes will factor the dependencies in when determining the
		order in which migrations and evolutions will apply.

Commits:

	Summary	ID
	Add utilities for fetching dependencies for an evolution or its app. Django Evolution 2.1 is getting support for dependencies defined in evolutions, allowing a single evolution or all evolutions for an app to apply before or after other evolutions or migrations. These can be specified as an app-level dependency (in the `evolutions/__init__.py`) or an evolution-level dependency by setting the following: * `BEFORE_EVOLUTIONS` * `BEFORE_MIGRATIONS` * `AFTER_EVOLUTIONS` * `AFTER_MIGRATIONS` Each is a list of items, where each item is either a string containing an app label or a tuple containing an app label and evolution/migration name. This change begins adding support for this by introducing utility functions that will look up these dependencies. `get_evolution_app_dependencies()` will fetch the dependencies specified at the top-level `evolutions/__init__.py` for an app, and `get_evolution_dependencies()` will fetch those defined in a particular evolution. Upcoming changes will factor the dependencies in when determining the order in which migrations and evolutions will apply.	d4555012d2a829f57c479675b8fd82d91d759757
	Add utilities for fetching dependencies for an evolution or its app. Django Evolution 2.1 is getting support for dependencies defined in evolutions, allowing a single evolution or all evolutions for an app to apply before or after other evolutions or migrations. These can be specified as an app-level dependency (in the `evolutions/__init__.py`) or an evolution-level dependency by setting the following: * `BEFORE_EVOLUTIONS` * `BEFORE_MIGRATIONS` * `AFTER_EVOLUTIONS` * `AFTER_MIGRATIONS` Each is a list of items, where each item is either a string containing an app label or a tuple containing an app label and evolution/migration name. This change begins adding support for this by introducing utility functions that will look up these dependencies. `get_evolution_app_dependencies()` will fetch the dependencies specified at the top-level `evolutions/__init__.py` for an app, and `get_evolution_dependencies()` will fetch those defined in a particular evolution. Along with checking an evolution's specified dependencies, `get_evolution_dependencies()` will also check if any mutations have dependencies to inject. This is a new feature of mutations. Currently only `MoveToDjangoMigrations` implements mutation-defined dependencies, and ensures that the evolution will apply after the migrations it applies to. This ensures that for a new database (or new app), the migrations will always apply first (since the intent is to ultimately have the app use them instead of evolutions). For an existing app, the evolver will already make sure those migrations are marked as applied by scanning ahead for this mutation, and it's important that the evolution doesn't try to apply before this step happens. Upcoming changes will factor the dependencies in when determining the order in which migrations and evolutions will apply.	c1c0fba6cec02d667eebb90b873cb952df039757

Diff:

Revision 2 (+740)

Show changes

	django_evolution/mutations.py
	django_evolution/tests/test_evolution_utils.py
	django_evolution/tests/app_deps_app/__init__.py
	django_evolution/tests/app_deps_app/models.py
	django_evolution/tests/app_deps_app/evolutions/__init__.py
	django_evolution/tests/app_deps_app/evolutions/test_evolution.py
	django_evolution/tests/evolution_deps_app/__init__.py
	django_evolution/tests/evolution_deps_app/models.py
	4 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:


Migration dependencies can no longer just specify an app label. They must be a tuple.
Added "real" migrations to migrations_app, to ease testing.
Added new evolutions_app2 and migrations_app2 modules to work as anchor points for deps in tests.
Updated the deps in app_deps_app and evolution_deps_app to point to real modules instead of fake ones.

Description:

		Django Evolution 2.1 is getting support for dependencies defined in
		evolutions, allowing a single evolution or all evolutions for an app to
		apply before or after other evolutions or migrations. These can be
		specified as an app-level dependency (in the `evolutions/__init__.py`)
		or an evolution-level dependency by setting the following:

		`BEFORE_EVOLUTIONS`
		`BEFORE_MIGRATIONS`
		`AFTER_EVOLUTIONS`
		`AFTER_MIGRATIONS`

		Each is a list of items, where each item is either a string containing
~		an app label or a tuple containing an app label and evolution/migration
~		name.
	~	an app label (for evolutions) or a tuple containing an app label and
	~	evolution/migration name (for evolutions and migrations).

		This change begins adding support for this by introducing utility
		functions that will look up these dependencies.
		`get_evolution_app_dependencies()` will fetch the dependencies specified
		at the top-level `evolutions/__init__.py` for an app, and
		`get_evolution_dependencies()` will fetch those defined in a particular
		evolution.

		Along with checking an evolution's specified dependencies,
		`get_evolution_dependencies()` will also check if any mutations have
		dependencies to inject. This is a new feature of mutations.

		Currently only `MoveToDjangoMigrations` implements mutation-defined
		dependencies, and ensures that the evolution will apply after the
		migrations it applies to. This ensures that for a new database (or new
		app), the migrations will always apply first (since the intent is to
		ultimately have the app use them instead of evolutions). For an existing
		app, the evolver will already make sure those migrations are marked as
		applied by scanning ahead for this mutation, and it's important that the
		evolution doesn't try to apply before this step happens.

		Upcoming changes will factor the dependencies in when determining the
		order in which migrations and evolutions will apply.

Commits:

	Summary	ID
	Add utilities for fetching dependencies for an evolution or its app. Django Evolution 2.1 is getting support for dependencies defined in evolutions, allowing a single evolution or all evolutions for an app to apply before or after other evolutions or migrations. These can be specified as an app-level dependency (in the `evolutions/__init__.py`) or an evolution-level dependency by setting the following: * `BEFORE_EVOLUTIONS` * `BEFORE_MIGRATIONS` * `AFTER_EVOLUTIONS` * `AFTER_MIGRATIONS` Each is a list of items, where each item is either a string containing an app label or a tuple containing an app label and evolution/migration name. This change begins adding support for this by introducing utility functions that will look up these dependencies. `get_evolution_app_dependencies()` will fetch the dependencies specified at the top-level `evolutions/__init__.py` for an app, and `get_evolution_dependencies()` will fetch those defined in a particular evolution. Along with checking an evolution's specified dependencies, `get_evolution_dependencies()` will also check if any mutations have dependencies to inject. This is a new feature of mutations. Currently only `MoveToDjangoMigrations` implements mutation-defined dependencies, and ensures that the evolution will apply after the migrations it applies to. This ensures that for a new database (or new app), the migrations will always apply first (since the intent is to ultimately have the app use them instead of evolutions). For an existing app, the evolver will already make sure those migrations are marked as applied by scanning ahead for this mutation, and it's important that the evolution doesn't try to apply before this step happens. Upcoming changes will factor the dependencies in when determining the order in which migrations and evolutions will apply.	c1c0fba6cec02d667eebb90b873cb952df039757
	Add utilities for fetching dependencies for an evolution or its app. Django Evolution 2.1 is getting support for dependencies defined in evolutions, allowing a single evolution or all evolutions for an app to apply before or after other evolutions or migrations. These can be specified as an app-level dependency (in the `evolutions/__init__.py`) or an evolution-level dependency by setting the following: * `BEFORE_EVOLUTIONS` * `BEFORE_MIGRATIONS` * `AFTER_EVOLUTIONS` * `AFTER_MIGRATIONS` Each is a list of items, where each item is either a string containing an app label (for evolutions) or a tuple containing an app label and evolution/migration name (for evolutions and migrations). This change begins adding support for this by introducing utility functions that will look up these dependencies. `get_evolution_app_dependencies()` will fetch the dependencies specified at the top-level `evolutions/__init__.py` for an app, and `get_evolution_dependencies()` will fetch those defined in a particular evolution. Along with checking an evolution's specified dependencies, `get_evolution_dependencies()` will also check if any mutations have dependencies to inject. This is a new feature of mutations. Currently only `MoveToDjangoMigrations` implements mutation-defined dependencies, and ensures that the evolution will apply after the migrations it applies to. This ensures that for a new database (or new app), the migrations will always apply first (since the intent is to ultimately have the app use them instead of evolutions). For an existing app, the evolver will already make sure those migrations are marked as applied by scanning ahead for this mutation, and it's important that the evolution doesn't try to apply before this step happens. Upcoming changes will factor the dependencies in when determining the order in which migrations and evolutions will apply.	721e175f57a67ed75b77974c181b6e3262216dc5

Diff:

Revision 3 (+914 -4)

Show changes

	django_evolution/mutations.py
	django_evolution/tests/test_evolution_utils.py
	django_evolution/tests/app_deps_app/__init__.py
	django_evolution/tests/app_deps_app/models.py
	django_evolution/tests/app_deps_app/evolutions/__init__.py
	django_evolution/tests/app_deps_app/evolutions/test_evolution.py
	django_evolution/tests/evolution_deps_app/__init__.py
	django_evolution/tests/evolution_deps_app/models.py
	17 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Change Summary:


Added models to the migration test apps and actual migrations.
Fixed up dependencies in evolutions_app2 to be real and not fake.
Updated a unit test suite to use MigrationsTestsMixin, and expanded that mixin to clear migrations from migrations_app and migrations_app2.

Commits:

	Summary	ID
	Add utilities for fetching dependencies for an evolution or its app. Django Evolution 2.1 is getting support for dependencies defined in evolutions, allowing a single evolution or all evolutions for an app to apply before or after other evolutions or migrations. These can be specified as an app-level dependency (in the `evolutions/__init__.py`) or an evolution-level dependency by setting the following: * `BEFORE_EVOLUTIONS` * `BEFORE_MIGRATIONS` * `AFTER_EVOLUTIONS` * `AFTER_MIGRATIONS` Each is a list of items, where each item is either a string containing an app label (for evolutions) or a tuple containing an app label and evolution/migration name (for evolutions and migrations). This change begins adding support for this by introducing utility functions that will look up these dependencies. `get_evolution_app_dependencies()` will fetch the dependencies specified at the top-level `evolutions/__init__.py` for an app, and `get_evolution_dependencies()` will fetch those defined in a particular evolution. Along with checking an evolution's specified dependencies, `get_evolution_dependencies()` will also check if any mutations have dependencies to inject. This is a new feature of mutations. Currently only `MoveToDjangoMigrations` implements mutation-defined dependencies, and ensures that the evolution will apply after the migrations it applies to. This ensures that for a new database (or new app), the migrations will always apply first (since the intent is to ultimately have the app use them instead of evolutions). For an existing app, the evolver will already make sure those migrations are marked as applied by scanning ahead for this mutation, and it's important that the evolution doesn't try to apply before this step happens. Upcoming changes will factor the dependencies in when determining the order in which migrations and evolutions will apply.	721e175f57a67ed75b77974c181b6e3262216dc5
	Add utilities for fetching dependencies for an evolution or its app. Django Evolution 2.1 is getting support for dependencies defined in evolutions, allowing a single evolution or all evolutions for an app to apply before or after other evolutions or migrations. These can be specified as an app-level dependency (in the `evolutions/__init__.py`) or an evolution-level dependency by setting the following: * `BEFORE_EVOLUTIONS` * `BEFORE_MIGRATIONS` * `AFTER_EVOLUTIONS` * `AFTER_MIGRATIONS` Each is a list of items, where each item is either a string containing an app label (for evolutions) or a tuple containing an app label and evolution/migration name (for evolutions and migrations). This change begins adding support for this by introducing utility functions that will look up these dependencies. `get_evolution_app_dependencies()` will fetch the dependencies specified at the top-level `evolutions/__init__.py` for an app, and `get_evolution_dependencies()` will fetch those defined in a particular evolution. Along with checking an evolution's specified dependencies, `get_evolution_dependencies()` will also check if any mutations have dependencies to inject. This is a new feature of mutations. Currently only `MoveToDjangoMigrations` implements mutation-defined dependencies, and ensures that the evolution will apply after the migrations it applies to. This ensures that for a new database (or new app), the migrations will always apply first (since the intent is to ultimately have the app use them instead of evolutions). For an existing app, the evolver will already make sure those migrations are marked as applied by scanning ahead for this mutation, and it's important that the evolution doesn't try to apply before this step happens. Upcoming changes will factor the dependencies in when determining the order in which migrations and evolutions will apply.	deb683e014dad3af505f66af8692ea603f522e3f

Diff:

Revision 4 (+1032 -16)

Show changes

	django_evolution/mutations.py
	django_evolution/tests/base_test_case.py
	django_evolution/tests/test_evolution_utils.py
	django_evolution/tests/app_deps_app/__init__.py
	django_evolution/tests/app_deps_app/models.py
	django_evolution/tests/app_deps_app/evolutions/__init__.py
	django_evolution/tests/app_deps_app/evolutions/test_evolution.py
	django_evolution/tests/evolution_deps_app/__init__.py
	19 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Status: Closed (submitted)

Change Summary:

Pushed to master (bc48632)