Suggestion: Migrate pulser-pasqal library inside pasqal-cloud

[MatthieuMoreau0]

Context

During a post-mortem session (with @awennersteen @CdeTerra & @madagra) where we investigated bugs that touched some of our applications which span across several projects owned between different teams, we came to the conclusion that it would be sensible to move the pulser-pasqal library into this repo.

What we suggest

• Removing the pulser-pasqal extension package from pulser.
• Moving the code to the pasqal-cloud repository (here). This repo would expose several backends that could be used by users to simulate their pulser sequences, using the newly reworked backend interface.
• Add a link in the pulser documentation to this repo that suggest user to install this pulser extension to use remote backends

Motivations

• Python dependency version management would become easier: only a single library version to manage which means it becomes easier to upgrade in all our services and no version incompatibilities to handle. We would add pulser to this package dependencies; the supported Pulser version from the SDK will match with the versions supported by the cloud platform.
• testing: it would make it easier for the cloud team to create end-to-end tests using the pulser-pasqal features and assert that no regression or bugs were introduced. This would make our test battery closer to how we expect our users to use the cloud platform.
• Decouple pulser-pasqal release cycle from the cloud SDK release cycle: in case of a hotfix patch to apply for the remote backend, we wouldn't need to release a new version of pulser (which seems overkill)

We discussed other points but I can't quite recall them all, so please add them in the comments of this issue

@HGSilveri what do you think about this? That's probably worth a discussion so we can organize a meeting to discuss this further.

[HGSilveri]

No strong objections on my end, but I do have some remarks:

What we suggest

• Removing the pulser-pasqal extension package from pulser.
• Moving the code to the pasqal-cloud repository (here). This repo would expose several backends that could be used by users to simulate their pulser sequences, using the newly reworked backend interface.

Where exactly? Is it inside pasqal-cloud? Note that pulser-pasqal depends on pulser-core, so this case would effectively make pulser-core a dependency of pasqal-cloud (which is something we avoided so far).

• Add a link in the pulser documentation to this repo that suggest user to install this pulser extension to use remote backends

Motivations

• Python dependency version management would become easier: only a single library version to manage which means it becomes easier to upgrade in all our services and no version incompatibilities to handle. We would add pulser to this package dependencies; the supported Pulser version from the SDK will match with the versions supported by the cloud platform.

Ok, so you want pasqal-cloud to enforce some restrictions on the pulser version. That makes sense, but we have to think about what the installation procedure will look like from the user's perspective. As an example, let's say that pasqal-cloud doesn't support the latest pulser version. In this case, if the user does

pip install pulser
pip install pasqal-cloud

they will run into dependency conflicts, right?

• testing: it would make it easier for the cloud team to create end-to-end tests using the pulser-pasqal features and assert that no regression or bugs were introduced. This would make our test battery closer to how we expect our users to use the cloud platform.

I agree it makes the test battery closer to the user experience. On the flipside, it will make it harder to catch when changes in pulser-core break pulser-pasqal. In the end, I guess it's just a matter of choosing based on what is most likely to happen.

• Decouple pulser-pasqal release cycle from the cloud SDK release cycle: in case of a hotfix patch to apply for the remote backend, we wouldn't need to release a new version of pulser (which seems overkill)

If SemVer rules are being respected, this is already accounted for since we pin the version of pasqal-cloud with ~= a.b.c, so it always installs the latest patch.

We discussed other points but I can't quite recall them all, so please add them in the comments of this issue

@HGSilveri what do you think about this? That's probably worth a discussion so we can organize a meeting to discuss this further.

• Will pulser-pasqal continue to be released as its own package, or will it be "absorbed" into pasqal-cloud?

• I think the issue boils down to managing compatibility between pulser and pasqal-cloud. Even if we move pulser-pasqal to pasqal-cloud, we will still need to take into account that the features in pulser-pasqal are not broken by changes in pulser-core.

• My intuition tells me that pulser-pasqal should remain close to pulser-core until the backend interface is crystallised and then moved close to pasqal-cloud.