Allow ignoring migrations from a specific application

[blimmer]

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]

Hi @blimmer

Would the exclude_apps option help in this case? Maybe you don't need to lint all waffle migrations and can simply ignore the entire library

[blimmer]

Hey @David-Wobrock - I proposed the same idea to my client I was implementing this for. They wanted to be aware in case future migrations in the waffle app might cause them problems during deployments. Since this particular 0001_inital is just a warning, we opted to include the app and just ignore that single warning.

It looks like Django uses 0001_initial as a naming convention, so I could see this being a useful feature in general.

That said, we're certainly not blocked. I appreciate your help and this library, so thank you for everything 😄

[David-Wobrock]

I completely understand the need, and it makes a lot of sense.
The linter is missing features/options to ignore migrations in a fine-grained manner 🤔

I'll keep the issue open for now, in order to reflect on possible ways to make this available.
One way would be to add an option to specify couples of migration to ignore --ignore-migration waffle 0001_initial for instance, but I don't want it to be redundant with other ignore options 🤔

[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 💡 🤔

[David-Wobrock]

Why not, good suggestion 👍

Let's reflect on that a little bit

[blimmer]

Sure thing. If you went this route, it might be nice to have a little debugger method like --list-all-migrations and --list-linted-migrations.

The nice part about --list-all-migrations is that you could paste the output into a site like https://pythex.org/ to write your regex. Then you could confirm that --list-linted-migrations is what you expect.