chore(pipeline): add deprecated PipelineConfigError

[nritsche]

PipelineConfigError was removed in 8f22399 but was still used outside of
caput. This adds a deprecated version.

BREAKING CHANGE: caput.pipeline.PipelineConfigError is deprecated and
will be removed in July 2021. Use caput.config.CaputConfigError instead.

Closes #155

[lgtm-com]

This pull request introduces 1 alert when merging 37b507a into 2a92a28 - view on LGTM.com

new alerts:

• 1 for Module is imported with 'import' and 'import from'

[tristpinsm]

what is the reason for deprecating PipelineConfigError? Can't it just live on as a child of CaputConfigError?

[nritsche]

what is the reason for deprecating PipelineConfigError? Can't it just live on as a child of CaputConfigError?

caput now prints line numbers and config file names when there is an error in a config. It didn't make sense to add this functionality to caput.pipeline and I added it to caput.config. Instead of having two redundant exception classes, I removed PipelineConfigError.

I found a total of 3 usages outside of caput. Is it used a lot in scripts people write, or what other reason is there not to remove it?

[tristpinsm]

Well so far the change has broken a few things, which should now be fixed, but I don't think it's unreasonable to think other uses could have been overlooked. And we might consider that caput is a public repository, so we can't audit all the code that was based on it.

If there is no functional reason to avoid keeping this around and maintaining compatibility I guess my thought is why not?

[nritsche]

Well so far the change has broken a few things, which should now be fixed, but I don't think it's unreasonable to think other uses could have been overlooked. And we might consider that caput is a public repository, so we can't audit all the code that was based on it.

We can keep it around for a while as deprecated, so other instances of it still being used can be fixed.

[tristpinsm]

Sure, I just fail to see the harm in having an alias remain available. But I don't feel very strongly about it either way

[jrs65]

I agree with @tristpinsm that we probably need to be a little more conscious about not changing caput's public API. The FRB group makes fairly heavy use of caput, especially the pipeline functionality, and we have no way of knowing what they're doing.

[nritsche]

I agree with @tristpinsm that we probably need to be a little more conscious about not changing caput's public API. The FRB group makes fairly heavy use of caput, especially the pipeline functionality, and we have no way of knowing what they're doing.

Do you want to give them more time but eventually remove it, or just keep an alias without deprecating it?

[jrs65]

I think deprecating it is fine, and the timescale of July seems reasonable, although I don't see why we need to be so aggressive, so maybe move it to December.

My point was mostly that for caput we can't assume that we are the only users and need to be more careful before introducing breaking changes to the public API, something for both people writing and reviewing code to be aware of.

[nritsche]

Alright, thanks @jrs65 and @tristpinsm.
I set it to December 2021.