Remove DLPack device number from arrays (revert #212)

[betatim]

In #212 we changed the device ID reported by the "not CPU" devices in array-api-strict. I think we should revert that change again. For one my original use-case has probably gone away but more importantly it seems to break torch.from_dlpack (and maybe others).

In scikit-learn/scikit-learn#34456 you have what happens in a scikit-learn test where we try to move an array from one namespace to another. Neither device really uses CUDA, but torch tries to use its CUDA machinery because array-api-strict device claims to be a CUDA device. I haven't tried but I assume that if I had a torch with CUDA support installed this would break at a later stage when it tries to access the actual memory.

All this makes me think that faking the device ID is a step too far.

If we decide to do this we also need to check the device ID reported by the other devices in array-api-strict ("no_float64")

A related thought is: what testing could we add to the array-api-strict test suite so that we'd have caught this problem before merging the PR. Should we have a CI job that runs some tests that are about checking compatibility/interaction with a library like torch?

[ev-br]

Sigh.
Telling people to uninstall torch is definitely the least appealing option!

Two questions:

• Since this was added specifically aiming scikit-learn testing, does it allow some usages and break some others, or just breaks the test suite full stop?
• If the goal was to be able to tell "this arrays is on a device which is not CPU", could adding a layer of indirection help? (the ultimate answer to all SE problems). Either an array-api-strict specific flag, or an xp_device_is_cpu(array: Array) -> bool kind of helper? So that "normal" backends just reuse the dlpack_device and array-api-strict does something else (and if so, what?).

A related thought is: what testing could we add to the array-api-strict test suite so that we'd have caught this problem before merging the PR. Should we have a CI job that runs some tests that are about checking compatibility/interaction with a library like torch?

Cross-library CI is hard :-). Off the cuff, it seems like we'd needed a real GPU run to detect the problem, and that's a big lift?

[betatim]

For now this change breaks things that used to work/work with array-api-strict 2.5. The original use-case was part of scikit-learn/scikit-learn#34324 which is still up in the air (but I'm pretty sure that I don't want to do the "detect if this is on CPU" bit).

That is why I think reverting this change is the simplest thing. All the other options feel like adding layers on top of layers. If the need for this ever comes back, we could reconsider what the best thing to do is?

[lucascolley]

a revert and leaving an open issue seems like a good idea for now