Future of InfoProviders

[d-buchmann]

The title may sound a bit pathetic...
I think despite this software being at global scope, users (like me) might be interested in implementing local/regional distributors and/or manufacturers, because more and more seem to be offering APIs.

For me, that raises the question if all of these can/should be merged into the main project, or if you could bump up the InfoProviderService into a full-fledged plugin system, where some plugins of global players could be provided alongside with Part-DB, and the user can add their own.
But ideally as a single file, so you wouldn't have to fork Part-DB and pull master for every new release. I suppose it's a rather small step, because the only files to touch for a new provider are the new php class itself, services.yaml, .env.local and optionally the oauth yaml as far as I'm concerned.
However, I'm not a webdev and not familiar with symfony, so I wouldn't know how to tackle this :/

[jbtronics]

In the Moment I don't see that a big problem of putting these providers into the main line code. As long as the providers are not enabled by configuration, they don't really hurt and are not really visible to the users too.
Maybe in the future this will change, but in the moment I think that's the easiest way.

However in principle symfony already have a kind of plugin system called bundles ( https://symfony.com/doc/current/bundles.html), which could be used to encapsulate the providers. Then you would just need to do a composer require to install the plugin.