This is basically what's already implemented here, no?

My idea would be something like:

def available_backends():
   ...

available_backends()
#
# {
#    "numpy": True,
#    "numba": True,
#    "cupy": False,
#    ...
# }

At the moment, even the whole list of possible backends (not actually available ones) is not accessible as a variable, but it's contained in the conditions of a series of ifs.

@alecandido I understand. What I was saying is that one could basically repackage that part of the code as a standalone function and it would already do the job (even if not in the most elegant way)

Yes, that's fine, we could definitely use it.

We're missing something like what is partially in GlobalBackend:

Moreover, since the mechanism of platforms is more or less uniform (though not fully, with built-in ones being the exception), most likely it should be something like:

{
    "core": {
        "numpy": True,
        "tensorflow": True,
    },
    "qibojit": False,
    "qibolab": {
        "tii1q_b1": True,
        "iqm5q": True,
        ...,
    },
    "qibotn": { ... },
}

and register some tiny classes that include the platform discovery mechanism for each of them (instead of implementing all of them in Qibo - it is already like this in Qibolab, but it's just a function).

The class could be just:

class MetaBackend:
    def load(platform: str) -> Backend:
        ...

   def list() -> dict[str, bool]:
       """Having dict mapping to bool could be equivalent to have a list
          for some backends, e.g. Qibolab, but used by others to check dependencies
          and hardware availability, e.g. Qibojit.
      """
      ...

(there is some confusion among the names "backend", "platform", so I chose a different one to disambiguate - but names are all up for discussion)

Ok, so, just to make sure that I have understood. The MetaBackend should take over the role of the current construct_backend function?
Namely, it will be capable of constructing the selected backend, but in addition also able to list the available backends. However, the mechanism for listing the available backends is still going to go through a bunch of try/except statements, right?

MetaBackend was a random name and random structure. But the goal was to make it hierarchical.

So, if you want to have a single set_backend() that accepts a string, you still need to register the various MetaBackend in qibo, with a construct_backend() function.
The idea is to make this registration simple, and agnostic of the internal structure of the other packages, so to register one MetaBackend per external package (one for qibojit, one for qibolab, one for qibotn, one for qibo-cloud, and even just a single one for the built-in).

However, the mechanism for listing the available backends is still going to go through a bunch of try/except statements, right?

In my mind, this should have been up to the individual backends.
E.g. if you have in mind qibojit, for sure: you could either try/except for dependencies, or you could check if a GPU is available and similar.
However, for Qibolab there is no try/except, you should just list the platforms available reading them from the proper folder.

@alecandido can you check whether this qibojit MetaBackend object goes in the direction you suggested?

Yes, definitely

I created an analogous MetaBackend class in qibo that is going to use all the different MetaBackend objects defined in the other repos. Qibojit's one is ready, I guess I will work on the qibolab's and qibo-cloud-backends' one (for this last one I was also thinking about changing the name of the repo to qibocloud).

Maybe the MetaMetaBackend should not be named MetaBackend on its own, and they could be just separate functions, you do not need even a class to collect them.

But it's fine to have something, and to make it work. Then we can refine how it looks like.