Add support for Python 3.12

[garrison]

This is very premature (UPDATE: no longer premature, see #429 (comment) but CI now passes), but it provides us a branch to test against Python 3.12 as dependencies catch up. I "un-did" some of the changes in #325 here, as cplex is likely to be the last dependency to support Python 3.12. (Then again, I could be surprised, especially if some other dependencies find it difficult to upgrade.)

[garrison]

I think the current error may resolve when symengine/symengine-wheels#11 is fixed. (symengine.py is already shown to work with Python 3.12.)

See also Qiskit's Python 3.12 tracking issue: Qiskit/qiskit#10887

Here's what I see why I try to run tox -e py312 locally on this branch:

Collecting symengine<0.10,>=0.9 (from qiskit-terra>=0.21.0->qiskit-aer>=0.12.0)
  Using cached symengine-0.9.2.tar.gz (85 kB)
  Preparing metadata (setup.py) ... error

  error: subprocess-exited-with-error
  
  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [24 lines of output]
      /home/garrison/serverless/circuit-knitting-toolbox2/.tox/py312/lib/python3.12/site-packages/setuptools/__init__.py:80: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated.
      !!
      
              ********************************************************************************
              Requirements should be satisfied by a PEP 517 installer.
              If you are using pip, you can try `pip install --use-pep517`.
              ********************************************************************************
      
      !!
        dist.fetch_build_eggs(dist.setup_requires)
      error: Multiple top-level packages discovered in a flat-layout: ['cmake', 'symengine'].
      
      To avoid accidental inclusion of unwanted files or directories,
      setuptools will not proceed with this build.
      
      If you are trying to create a single distribution with multiple packages
      on purpose, you should not rely on automatic discovery.
      Instead, consider the following options:
      
      1. set up custom discovery (`find` directive with `include` or `exclude`)
      2. use a `src-layout`
      3. explicitly set `py_modules` or `packages` with a list of names
      
      To find more information, look for "package discovery" on setuptools docs.
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

[coveralls]

Pull Request Test Coverage Report for Build 7895862170

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 93.541%

---

Totals
Change from base Build 7876868388:	0.0%
Covered Lines:	2346
Relevant Lines:	2508

---

💛 - Coveralls

[garrison]

It looks like we will need to wait for a version of Qiskit to be released that removes the pin symengine>=0.9, <0.10, as there are only Python 3.12 wheels for symengine 0.11.0 (symengine/symengine-wheels#12). Note that the Qiskit PR that adds support for Python 3.12 changes this pin to be symengine>=0.9,!=0.10.0, so as soon as this PR makes it into a released version of Qiskit (and as soon as we are compatible with this version of Qiskit -- see #406 (comment)), then we should be able to support Python 3.12 too. It would be nice if Qiskit were to backport their PR and include it in a 0.45.X release; then we wouldn't have to wait for (compatibility with) 1.0 to have Python 3.12 support.

[mtreinish]

My intent is to backport Qiskit/qiskit#11262 once it's working (it's failing rightnow because subunit, a test dependency, is emitting deprecation warnings on import with 3.12). We typically try to include support for new python versions in a release ASAP.

[garrison]

Quantum Serverless (really Ray) does not yet support Python 3.12, so I disabled its install in the notebook tests too. Once QS and cplex catch up, we can remove the special cases for Python 3.12.

[garrison]

Ref ray-project/ray#40211 (comment)

[caleb-johnson]

So we report that we support it in the package description, but you do not want to add a README shield?

I wonder if we should not report that we support 3.12 at all until CPLEX catches up or we remove it in favor of a replacement cut-finding package

[garrison]

So we report that we support it in the package description, but you do not want to add a README shield?

Actually, the README shield is generated these days by querying the latest released version on pypi, so this PR (plus a release) will result in the shield being updated:

https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/a666e696486b58798084b231eb4ccc76640b5a64/README.md#L7

I wonder if we should not report that we support 3.12 at all until CPLEX catches up or we remove it in favor of a replacement cut-finding package

I think it's fine to say we support it in terms of the Trove classifiers, because we do. Partial functionality works, and full functionality will work once there are cplex wheels. But yeah, reasonable people could have different takes on this. I do think it's worth pointing out that one should currently expect only partial functionality under Python 3.12, and this is what the note in INSTALL.rst is for.

Long term it'd of course be nice to remove the current cplex stuff in favor of #471.

[garrison]

CI should pass once a release is made that contains Qiskit/qiskit-ibm-runtime#1449 (i.e., after the next qiskit-ibm-runtime release).

[garrison]

qiskit-ibm-runtime 0.21 has been released, and CI now passes for this PR. The status indicator is yellow, though, because github expects to see a Python 3.11 check but sees a Python 3.12 check instead. @caleb-johnson, if you are good with merging, I can modify the expected check thru the github admin and then merge this.

[caleb-johnson]

qiskit-ibm-runtime 0.21 has been released, and CI now passes for this PR. The status indicator is yellow, though, because github expects to see a Python 3.11 check but sees a Python 3.12 check instead. @caleb-johnson, if you are good with merging, I can modify the expected check thru the github admin and then merge this.

Thanks, I've been keeping an eye on this PR. LGTM