Make cell-magics opt-in rather than opt-out

[MarcoGorelli]

Currently, nbqa tries to process all cell magics except those in

nbQA/nbqa/save_source.py

Lines 31 to 51 in a99e0e2

	MAGIC = [
	"%%!",
	"%%bash",
	"%%cython",
	"%%HTML",
	"%%html",
	"%%javascript",
	"%%js",
	"%%latex",
	"%%markdown",
	"%%perl",
	"%%python2",
	"%%ruby",
	"%%script",
	"%%sh",
	"%%sx",
	"%%system",
	"%%SVG",
	"%%svg",
	"%%writefile",
	]

I think we should do the opposite: never process cell magics, except for some hard-coded common ones like matplotlib inline and timeit, + add a command-line argument so users can pass extra ones they might want to process

This means deprecating nbqa_ignore_cells and instead adding nbqa_process_cells.

IMO it's OK to make a 0.6.0 release with this breaking change in - this is a relatively new project, and it's not like the user-base is large enough that we need to go through a deprecation cycle

cc @nbQA-dev/nbqa-core in case anyone has any comments - else I'll try to work on during the weekend

[girip11]

@MarcoGorelli: Should we give a deprecation warning and then remove it in the 0.6.1? Do you think keeping both old and new flags would be difficult for 1 or 2 releases ? I was thinking of making a simple change like nbqa_process_cells will get removed from the current ignore list in the code. So that it not a breaking change for now.

But I completely agree with you on users giving what to process rather than nbqa expecting what to ignore.

[MarcoGorelli]

I'd suggest keeping the old flag but just letting it throw a a loud and clear error telling users that it's no longer valid. Having both flags seems a bit too complicated to me

Should we give a deprecation warning and then remove it in the 0.6.1?

I think it'd be more typical to remove in the next minor release (0.7.0), which is a bit too far away - either way, without having yet reached 1.0.0, we're not yet bound by such rules and can make bigger changes without warning

[girip11]

I'd suggest keeping the old flag but just letting it throw a a loud and clear error telling users that it's no longer valid.

This idea is fine. I am fine with even removing the flag straightaway. But the reason why I hesitated was some of the projects in the used by section contains big ones. So if the flag is removed, wouldn't their CI start failing?

[MarcoGorelli]

That's a good point, though which of those projects uses the flag? I had a look, but couldn't find any of them using it

[girip11]

Then removing the flag should be OK.

[s-weigand]

IMHO making the option error or at least warn that it will be ignored, and point to this issue or somewhere in the docs is the most user-friendly and yet simple solution.

[MarcoGorelli]

Yup - have gone with erroring in #559