Generate updates

[alecandido]

This is something I said many times, but it seems I never wrote it.

The idea is to create updates in routines as objects (most likely, as dictionaries), instead of modifying dynamically an instance (the Platform).

This will have several benefits:

• no need to propagate the update flag within the routine: you can always run the update, and always save it
• you can later decide (at any time) which subset of updates you want to apply
• it will finally allow the time travel, resuming the execution from a certain state of the Platform, with different routines (without re-executing the previous ones)
• part of these features may even be exposed to qq update (cf. #833 #905)

The idea is that applying updates will be supported directly by Qibolab. But, in case Qibocal moves faster in this direction, this can also be implemented in here, and migrated later on.

[andrea-pasquale]

The idea is to create updates in routines as objects (most likely, as dictionaries), instead of modifying dynamically an instance (the Platform).

Here I'm a bit confused. In the past Qibocal was already generating updates in the form of dictionaries, which were passed to the platform that was updating itself based on those dictionaries. I believe that since the update in qibolab was a bit messy we decided to let qibocal handle the update of the platform https://github.com/qiboteam/qibolab/pull/596. Moreover, I think that this will also generate more entanglement between qibolab and qibocal, and I believe that we were going into the opposite direction.

[andrea-pasquale]

What would make sense is to generate a serialization for the updates, but I still think that the update should be performed by qibocal.

[alecandido]

The idea, yet missing in Qibolab, is to be able to apply an update with a shape like:

{
  "single_qubit[1].RX.frequency": 5e7,
  "single_qubit[5].MZ.duration": 1.5e3,
  ...
}

These are the kind of updates I have in mind.

Then there will be a function, reading the keys into an AttributePath object (possibly a list[str]), that through __setattr__ and __setitem__ (or dataclasses.replace), will apply this update to an existing platform object (or just to its serialization, slightly more inconvenient).

The overall feature will be simple: parse the path splitting on {.[]} characters, and then iteratively access the inner object, to eventually mutate atomic attributes (the equivalent with immutable objects might be just more annoying - but if Qibolab makes use of immutable objects, which I support, we will need to address even that, recursively replacing in the innermost object, and from there on).

The update(platform, flattened_update) function could be implemented both in Qibolab and Qibocal, but it is general enough that making it part of Qibolab it's not going to hurt. However, even in Qibocal should be good enough, since it will not depend on the specific structure of the qibolab.Platform object, but it will just be a notation to update a whatever nested Python object.