Radomir Stevanovic

I'm not sure how it can work, because `id_` refers to problem id (i.e. "job id"), and `sample_cqm` requires uploaded problem id (a.k.a `bqm_id`).

Or if you realize you want to re-submit a hybrid problem long after the initial sampling, you can do: ```python # get problem id, either from Leap Dashboard, or your...

Functionally, it makes perfect sense to me to keep all of those as properties. `num_variables` (or `num_interactions` or `vartype`) is a property of BQM, regardless of implementation details, and the...

I hear the extensibility argument. If we proceed, I would be careful to keep [interfaces segregated](https://stackify.com/interface-segregation-principle/), unless BQM will subclass QM.

I like the `from future import feature` approach because it's simple-ish and explicit. If performance hit is too high (TBD?), we can break compatibility only once, but max twice: -...

Alternatively, extend `.to_file()` to accept optional fd where it would write instead of to a `SpooledTemporaryFile`.

It's perfectly consistent, IMO. `json.dump` takes an object and a file, and writes the object to that file. No reason it should rewind. Actually, I see a lot of reasons...

Looking at these fields, perhaps we should call them "structure", not metadata? I'm imagining "`bqm.info`" would be metadata. :shrug: Seems explicitly calling out `num_variables` and `num_interactions` would be clearer and...

That's exactly what `**runopts` in Hybrid are for -- but right now the interface is a mess and I'm working on generalization (under https://github.com/dwavesystems/dwave-hybrid/issues/141). It proved to be non-trivial.

Hi @29rou, thanks for contributing the issue and the PR. We have already looked into shipping arm64 wheels (see this issue on Ocean SDK repo: https://github.com/dwavesystems/dwave-ocean-sdk/issues/126), and we looked at...