`error` return value is always nil

[copejon]

No process within NewProvisioner() generates and error; the function will only ever return nil.

Let's remove the error return value from the function so consumers don't end up writing unnecessary error checks.

[guymguym]

It's really a non-issue, but still I don't think it's the right thing to do. Making such changes for saving the error checks that are probably just occurring in a single location in the code of every provider is not worth removing the error from the main initialization API call of a library. This just limits the flexibility of the library to improve. If providers don't want to handle errors explicitly in initialization they can panic or fatal. CC @travisn

[travisn]

Agreed that it's a very minor issue, but philosophically speaking...

If an API has no need to return an error, why return a placeholder that will always be nil? It will require unnecessary error handling by the caller.

With golang an API can change over time. Clients that need to update to the latest API would update their vendoring and then change their calls accordingly. So there is nothing preventing the API from changing if an error condition is added in the future.

[guymguym]

I philosophically don't mind it either way :)

BTW this is a SEMVER MAJOR change.

[guymguym]

I'm removing the "bug" label

[copejon]

Those are all pretty compelling reasons not to mess with it right now, closing.