Serving credentials to plugins

[pennylaneai]

Serving credentials to plugins

[cgogolin]

This is fully implemented in the ProjectQ plugin).

[cgogolin]

The only open thing is the configuration file issue, but that is maybe something separate.

[mariaschuld]

The second options would be very useful.

[smite]

Currently this type of information is stored in the PluginAPI._capabilities dictionary, which is specific to a plugin. Perhaps we should also add backend-specific dictionaries?

[smite]

I think a plugin that requires credentials but doesn't get them (via a keyword argument, probably) should just raise a ValueError.

[josh146]

I agree with @smite; I think it makes sense to have this fully implemented on the plugin/device side.

This way, the credentials would be completely encapsulated within the plugin/Device class, and passed along in a similar fashion as to other options (such as number of shots, cutoffs, etc.). Something like this:

dev1 = qm.device('ibm.qx4', shots=100, api_key='2321873csad98123bhjsd9')

or, equivalently,

dev1 = qm.device('ibm.qx4')
dev1.shot = 100
dev1.API_KEY = '2321873csad98123bhjsd9'

That way, a plugin can decide how to deal with missing credentials (i.e. raise a ValueError as suggested by Ville). The test suite for the plugin/device + credentials would then be contained in the plugin repo, instead of OpenQML.

In addition, when I implement the local config file for OpenQML, the plugins should also have the ability to read/write to their own sections. For instance, using something like TOML:

[openqml]
#general openqml settings here

[ibm.qx4]
default_shots = 100
api_key = "2321873csad98123bhjsd9"

[cgogolin]

The config file is the only real solution, imho.

In the first two cases users can no longer submit their source code to a public repository because it contains their credentials. Even we are "users" in this scenario, because it also prevents me from uploading an example that uses the IBM backend to the OpenQML repository without sharing my credentials with you :-). This is bad.

[josh146]

I agree. I think both should be available for flexibility (for instance, this allows the distribution of jupyter notebooks with api_key=# enter API key here in an input cell for the user to fill in after downloading), but the configuration file should be the recommended approach.

[co9olguy]

@cgogolin This is the only plugin that currently requires any credentials. Are we ok to close this issue, or any credentials-related code that needs to be backported into openqml proper?

[josh146]

We can keep this open for the configuration file, or close this and create a separate issue

[josh146]

Closed, implemented in #40.