Introduce braket_client

[mho291]

No description provided.

[alecandido]

@mho291 you should not use poetry lock to resolve the conflicts. But rather solve them manually, and then use poetry lock.
However, this is only relevant if you use poetry lock --no-update, since it will be aware of the current state. If you instead use poetry lock, it should recompute from scratch, so a convenient alternative becomes just deleting the conflicting poetry.lock with rm, and then run poetry lock to recreate it from scratch. In this case, it's truly impossible that the conflicts will stay (for the simple reason that they should not be recorded in any other place...)

For pyproject.toml, there are two areas to resolve:

However, here you're talking about pyproject.toml, not poetry.lock, which are definitely two separate files :)

my guess is we should add both instead of removing, since we need amazon-braket-sdk. Can I confirm if that's right?

Well, I can tell you that you should not do that, for the simple reason that the TOML file is like a dict, so you would have two equal keys - in the best case the loader will overwrite the former with the latter, in the worst it will just fail for the duplicated entry.

So, you have to choose. Which one to choose is a separate story. But the usage of extras is consistent in qibo-cloud-backends, and it should be recommended for any package providing multiple backends (since the user may need a single one, and reducing dependencies when possible is always making the installation and run more reliable).
I.e. you should only accept the optional, no reason to accept the one which is overwriting it.

For the poetry.lock file, will it suffice to accept the changes, except those that ask amazon-braket-sdk to be removed, using the web editor?

In any case, I don't see any residual conflict in the repo. So, it seems that you only have the conflicts and you never pushed them (which would be the correct thing to do).

Please, refrain from using the web editor: if you're unable to solve conflicts locally, that's a good reason to dig deeper. Not to propagate them to remote repo through a different path.

[mho291]

Thanks @alecandido , I have a better picture now.

I noticed that we are 113 commits ahead of, 20 commits behind qiboteam/qibo-cloud-backends:main.

So what I'm doing (currently still in progress) is to update the changes in accordance to the 20 commits we're behind. I've also included the amazon-braket-sdk dependency inside the pyproject.toml file for this pull request. And then generate a new poetry.lock file from scratch. After that, I will push.

Thanks a lot!

[alecandido]

So what I'm doing (currently still in progress) is to update the changes in accordance to the 20 commits we're behind. I've also included the amazon-braket-sdk dependency inside the pyproject.toml file for this pull request. And then generate a new poetry.lock file from scratch. After that, I will push.

To do this, I suggest to either do git rebase upstream main (which is my favorite option, but it may be a bit painful if you're not familiar with rebasing), or rather git merge upstream main.

And yes, this will generate conflicts, which in general you will need to solve manually. And that's also the case for pyproject.toml and poetry.lock (though, for the second one, the removal strategy is often a practical one - of course after pyproject.toml manual resolution).

[mho291]

So what I'm doing (currently still in progress) is to update the changes in accordance to the 20 commits we're behind. I've also included the amazon-braket-sdk dependency inside the pyproject.toml file for this pull request. And then generate a new poetry.lock file from scratch. After that, I will push.

To do this, I suggest to either do git rebase upstream main (which is my favorite option, but it may be a bit painful if you're not familiar with rebasing), or rather git merge upstream main.

And yes, this will generate conflicts, which in general you will need to solve manually. And that's also the case for pyproject.toml and poetry.lock (though, for the second one, the removal strategy is often a practical one - of course after pyproject.toml manual resolution).

Super! Thanks so much for the guidance!

[BrunoLiegiBastonLiegi]

Suggested change

	qiskit_ibm_provider = "^0.11"
	qiskit_ibm_provider = "^0.11"
	amazon-braket-sdk = "^1.83.0"

if in the docs you are running code examples with BraketClient you probably need the amazon-braket-sdk here as well, otherwise the docs deployment will fail.

Outdated

[alecandido]

@BrunoLiegiBastonLiegi I dismissed your review since it happened a while ago, so it made sense in general to confirm the opinion is unchanged.

If you still believe that this is good to go, and you don't need to take a further look, feel free to approve it again.

[mho291]

Hi! Wondering if we could expedite the merging of this. I have a few colleagues who will need to start using the cloud interface for their work in early November. Thank you!!

[BrunoLiegiBastonLiegi]

Sorry for the delay, I've been a little busy lately. This is still looking good to me, can you please just add the token argument to the backend even though it's not used?

[BrunoLiegiBastonLiegi]

Suggested change

	def __init__(self, device=None, verbatim_circuit=False, verbosity=False):
	def __init__(self, device=None, verbatim_circuit=False, verbosity=False, token: str=None):

For symmetry with the other backends can you add a token=None argument here, and raise a warning or an error if the user actually passes it.

[mho291]

I'm not sure if it's a good idea to leave token argument in just for symmetry with other cloud backends, because Braket doesn't need the token argument. A user may be confused and wonder if there will be a feature for token in future. What do you think? :)

[BrunoLiegiBastonLiegi]

I know that it may create some confusion, but I ultimately think that it would be better to uniform all the backends under the input arguments perspective. It should be fine, as long as this is well documented and/or warnings are raised for unused arguments.

[mho291]

Fair point. In that case, I'm thinking we could raise a warning:

import warnings
def __init__(self, device=None, verbatim_circuit=False, verbosity=False, token: str=None):
    if token:
        warnings.warn(
            f"Token is not needed for executing circuits on Amazon Braket devices.",
            category=UserWarning
        )

That way, the code can run even with token present. Do you think this is alright?

[alecandido]

Once more: refrain from warnings if you're not directly writing an app (i.e. a CLI or a graphical app).

Choose your favorite among:

• ignoring
• raise an error
• return some marker (possibly together with other values)

[mho291]

I might choose ignore because raise_error will stop the code from execution. But let me try all the options out on my end. Thanks a lot!

[BrunoLiegiBastonLiegi]

Suggested change

	if token:
	pass

thanks, we could even drop this if we decide to ignore it

[mho291]

Ok sure!

[BrunoLiegiBastonLiegi]

Thanks @mho291, I just checked that the braket tests are passing and they seem to (the errors come from the ibmq account in the secrets apparently). Personally I would merge this now as it looks good enough to me for the moment. We could iteratively improve on this in future with other PRs.
Thus, unless, there is any objection, I would merge this.

[mho291]

Hi @BrunoLiegiBastonLiegi , sounds great! Thanks so much for guiding and reviewing. Once merged, I will also create an issue with the following to remind us of what we discussed earlier.

Possibility of qibo -> qasm -> qiskit -> braket conversion.

• To do that, implement a function, either inside this backend or outside but called inside the execute_circuit here
• The function will build a qiskit circuit starting from the qibo generated QASM + some custom instructions through the qasm2.loads and overriding the qiskit.from_qasm
• Finally, make use of the existing qiskit -> braket conversion layer to create the braket circuit and send it through

The qasm->qiskit has problems:

• Qiskit uses r to represent the phase RX gate.
• Changing qibo's PRX qasm representation from prx to r doesn't work -- qasm loader for qiskit doesn't recognise it because it's not in qiskit's LEGACY_CUSTOM_INSTRUCTIONS. (See comment)
• Adding MY_CUSTOM_INSTRUCTIONS to LEGACY_CUSTOM_INSTRUCTIONS also doesn't work. (See comment)

[mho291]

Hi @BrunoLiegiBastonLiegi , since Braket client has been merged, is there a way to use it before the release? Thanks! :)

[BrunoLiegiBastonLiegi]

You just clone the repo (main branch) and do pip install . (or poetry install).
Alternatively, without cloning: pip install git+https://github.com/qiboteam/qibo-cloud-backends.

[mho291]

You just clone the repo (main branch) and do pip install . (or poetry install). Alternatively, without cloning: pip install git+https://github.com/qiboteam/qibo-cloud-backends.

Thanks very much!!