import error exposure

[RaymondWJang]

Hello,

love the library so far. just one thing - would it be possible to expose the error trace for opencv import error? took me a bit longer than it should've to figure out that i need to separately add opencv-python to the env, as the only error shown when i ran

video = VideoProxy(path=video_path)
return video.shape

was Nonetype is not callable. (because VideoCapture gets automatically initialized as None when there's a cv2 import error.)

[sneakers-the-rat]

We talked a bit about this in person, jotting down TODOs:

The problem here is that we want to be minimal dependency as possible while allowing for third part expansion/declaration of interfaces that aren't in numpydantic package proper. To do that, each interface has an enabled property that is True when its dependencies are met and it can be used. The Interface.match method finds an interface that signals that it can be used for a given input via its check method (see Interfaces), but sometimes those package dependencies are required for that check method to run. Currently if no other interface matches, we fall back to the numpy interface (see Matching, NumpyInterface.priority), but that spuriously matches the input from most other interfaces so it passes validation silently. (eg. np.array('video.mp4') satisfies NDArray[Any, Any])

What we want here is an error message for "this looks like something that could be used with {x} interface, but you don't have the dependencies for it."

To make that happen we would need to

• Check if we are simply falling back on numpy interface or if the thing is genuinely numpy input type (an np.ndarray or at least a list)
• Create a file_pattern class attribute (default None for interfaces that don't source arrays from files like dask and numpy) that matches against file names when they are passed as strings - this avoids requiring us to have the package dependencies to check if an interface is a match (and is probably faster in the case that we have been passed a string or tuple of strings)
• Make a more general declaration of dependencies than just the enabled method so it's possible to say "you need this to use it"
• Catch when we are inappropriately falling back on numpy and issue a warning like "couldn't find a good match, falling back to numpy. You currently have these interfaces enabled: {x}, and these ones are defined but disabled because their dependencies aren't met: {y}" and then if there was some fuzzy match from eg. a file pattern the warning could further recommend "this looks like a {z} interface input, to use it, install {dependencies}"