[Frontend] Refactor the process of adding a new device in the frontend about catalyst

[dime10]

@maliasadi, where would you say this issue stands, after #327 got merged?
At least the first point seems taken care of, but maybe the second is still relevant?

[erick-xanadu]

The installation and support of ever device shouldn't be checked by PennyLane a priori. Catalyst must have its own device checking mechanism to check the installed backend devices. Currently, the frontend heavily relies on PL device infra so that every backend device has to pip install, otherwise PL throws an error complaining that the plugin/device isn't installed!

Can you explain what you want here? Why does Catalyst need its own device checking mechanism to check the installed backend devices? Don't we want to converge with how PL treats devices?

[maliasadi]

The installation and support of every device shouldn't be dependent on PL a priori. Catalyst must have its own device checking mechanism to verify the installed backend devices. Currently, the frontend heavily relies on PL's device infrastructure, requiring every backend device to be installed via pip, otherwise, PL throws an error, complaining that the plugin/device isn't installed.

We're moving in an opposite direction with the device communication API. This suggestion is outdated.

Device options should be communicated through Catalyst and to the runtime, without the frontend needing to know hardcoded details about the devices.

That's on our roadmap and will be addressed by the communication API.

If the options must be cached/stored in the frontend, we can potentially utilize a dataclass that also facilitates the serialization of device_kwargs in the backend,

This is also not required anymore by getting the plugin systems fully implemented for all backend devices.

My main concerns regarding the addition of new backend devices have been thoroughly discussed in the past months and they have either been addressed or are now part of our roadmap. We are currently moving towards separating devices and dynamically loading them to improve scalability & flexibility, and we plan to implement a consistent device communication protocol. Let's close this issue as the objectives are being updated more in the opposite direction.