Versioned specs

[genematx]

Checklist

• Add a Changelog entry
• Add the ticket number which this PR closes to the comment section

[danielballan]

Currently, the registered entrypoint must point to a class implementing the interface of a BaseClient:

tiled/tiled/client/base.py

Lines 114 to 122 in 2d814d5

	def __init__(
	self,
	context: Context,
	*,
	item,
	structure_clients,
	structure=None,
	include_data_sources=False,
	):

It is instantiated like so:

tiled/tiled/client/utils.py

Lines 194 to 200 in 2d814d5

	return class_(
	context=context,
	item=item,
	structure_clients=structure_clients,
	structure=structure,
	include_data_sources=include_data_sources,
	)

With the addition in this PR, the target could either be a BaseClient or a function that takes a version and returns a BaseClient:

def f(version):
    if ...:
        return ClientA
    else:
        return ClientB

I thought of two different alternatives for consideration:

1. Dispatch on the complete spec.

def f(spec):
    ...

I could imagine cases where someone might register the same function f for more than one spec.name. In general I have found it prudent to provide callbacks with a "return address" of what they have been registered on. (See also #919 and caproto/caproto#547.)

2. Aim for type stability. In main, the regsitered entrypoint always has type BaseClient. If we introduce f, the interface becomes something like Union[BaseClient, Callable[str, BaseClient]] which is a bit more complex to reason about and test. It is possible to satisfy our requirements with one interface, insert spec at the beginning of the signature:

def f(spec, context, * item, structure_clients, structure, include_data_sources):
    if ...:
        return ClientA(context, item=item, structure_clients=structure_clients, ...)
    else:
        return ClientB(context, item=item, structure_clients=structure_clients, ...)

If all BaseClient instances were updated to have this interface (where spec may be None) we could have a type-stable interface for all.

---

I am open to the solution proposed this in PR---no strong concerns---but thought I would offer these for discussion.

[danielballan]

This is no longer needed for bluesky-tiled-plugins, so we're going to put this aside. We are open to adding something like this if there is a use case for it, but we won't add it proactively.