Allow ignoring migrations from a specific application

In our application, we’re using the waffle feature-flag library. The first migration they define (0001_initial) triggers warnings:

(waffle, 0001_initial)... WARNING
	CREATE INDEX locks table
	CREATE INDEX locks table
	CREATE INDEX locks table
	CREATE INDEX locks table
	CREATE INDEX locks table
	CREATE INDEX locks table
	CREATE INDEX locks table
	CREATE INDEX locks table
	CREATE INDEX locks table
	CREATE INDEX locks table
(waffle, 0002_auto_20161201_0958)... OK
(waffle, 0003_update_strings_for_i18n)... OK

As far as I can tell, the only way I can exclude this migration is by name (0001_initial). However, other apps will use this 0001_initial naming convention by default, as well.

It would be nice if we could somehow exclude this migration by name and app. That way, 0001_initial in the specified app would not be included, but 0001_initial in all other apps would be included.

[David-Wobrock]

Why not, good suggestion 👍

Let’s reflect on that a little bit

[blimmer]

👍 thanks for the response. If you’d be willing to make a breaking change, I wonder if you could change the way migrations are specified as parameters to <appname>.<id>.

What might be nice about passing these as strings is you could allow passing regex-like strings as well. Then you wouldn’t have to have the somewhat duplicative --ignore-name --ignore-name-contains flags. Using a regex would also invert the responsibility to the user to avoid overlap in how they’re including/excluding migrations.

For example, this would cover my use case:

--exclude 'waffle.0001_initial`

But you could also do other clever things like:

# old
--ignore-name '0001_initial'

# new
--exclude '*.0001_initial`

# old
--exclude-apps 'waffle'

# new
--exclude 'waffle.*'

This syntax might be less user-friendly than the current options but would allow for a lot of flexibility. Just a thought 💡 🤔