deprecate postprocessors

[minrk]

We've been slowly moving away from having postprocessors (PDFPostProcessor became PDFExporter), and before we get as far as adding new postprocessor features (#395), we should consider deprecating the concept of postprocessors entirely. nbconvert --post serve is the only existing postprocessor, and might be better turned into a dedicated nbconvert serve-slides entrypoint, so that re-rendering isn't required for serving. Plus, postprocessors don't run when used from the Python API.

#566, for instance, might be more logically implemented as a 'Writer', because its intent is to change what files are created, not create additional files, which is what a postprocessor would logically do.

[takluyver]

👍 I think postprocessors were an overgeneralisation that we don't really need.

I'm not even entirely convinced that we need a general notion of 'preprocessors', as opposed to a collection of utility functions and options on exporters. But as there are quite a few of those, that would involve a much more invasive change.

[damianavila]

+ 1 on the proposed change.

[nfultz]

I use postprocessors in nb2mail, please ping me if you deprecate postprocessors and let me know what I am supposed to use instead.

[takluyver]

One possible alternative is to use a writer class - so sending the email would replace the stage where output is written to disk. Alternatively, you could create a separate nb2mail command line script which uses the nbconvert Python API and then does whatever you like with the returned data.

That's an interesting use case, though; maybe it indicates that we should think more carefully about this.

[SylvainCorlay]

I'm not even entirely convinced that we need a general notion of 'preprocessors', as opposed to a collection of utility functions and options on exporters.

I think that this is essentially what preprocessor became in 6.0.

On postprocessors, +1 to deprecate them.

[MSeal]

I had taken a stab at this: #1289 -- but there was concerns around breaking existing usage. I'm still pro simplifying things but I think any significant change there would need to be post the 6.0 release unless we want it to delay that release substantially

[t-makaro]

We could remove postprocessors without any changes to preprocessors. I have seen a couple interesting use cases for postprocessors (when you don't want to make an exporter config option or template option it serves as a nice place for post conversion changes). However, I think that we either need to make better use of postprocessors or remove them.

Our only built in postprocessor is the ServePostProcessor.

[MSeal]

True

[MSeal]

Do we want to remove ServePostProcessor and cut to just PreProcessors? @maartenbreddels to get his input as well ?

[damianavila]

Do we want to remove ServePostProcessor and cut to just PreProcessors?

I would be OK with that as long as we have something replacing what that postprocessor does...

nbconvert --post serve is the only existing postprocessor, and might be better turned into a dedicated nbconvert serve-slides entrypoint, so that re-rendering isn't required for serving