explosion
Make the compat module private
As discussed, this module contains a lot of booleans that Thinc uses internally to keep track of what libraries and devices are available. However, we want to keep the freedom to rename or change the semantics of these booleans, so let's make the module private.
Can you change all the imports to import from util or api as much as possible rather than from _compat?
Can you change all the imports to import from
utilorapias much as possible rather than from_compat?
Do we really want this? To me has_.* are effectively private Thinc state variables that we use to keep track of what libraries/GPUs are available. Exposing them to the outside makes it harder to change/improve the semantics of these variables. E.g., currently we have has_torch_gpu which flags 'torch has access to a CUDA GPU', but should eventually mean 'torch has access to a GPU'. However, if we expose this officially through thinc.util we cannot give them the intended semantics, because someone may rely on has_torch_gpu to check whether there is a CUDA GPU.
The only use in spaCy of a has_ variable is has_cupy in the condition:
if has_cupy and gpu_is_available():
however, gpu_is_available() alone would suffice.
It's too late to treat them as actually private, though. I think we should treat everything that was previously in thinc.util in a release as part of the public API.
Then only new/private things would be imported from thinc._compat to make this distinction clearer.
I don't think this entirely rules out this kind of change to has_torch_gpu (at a minor version), but it shouldn't be removed from thinc.util or treated like it's private in terms of when backwards-incompatible changes might be made.
I have changed my view a bit on this module, and I think it's sometimes useful to probe whether Thinc has found CuPy, a GPU, etc. So I'll close this issue.