[stonea]

Currently, pennylane-qiskit (used by QFw) is specified to use qiskit<=2.3.0.

This is an issue since MQT wants to use Qiskit 2.5 or 2.6. Currently, in QFw-SLURM-Cluster we are putting MQT and QFw into separate virtual environments with separate versions of qiskit installed. This is an issue as we want to demo integrated MQT into QFw.

This PR force overrides to use qiskit==2.5.2.

This appears to be fine (or at least examples/qfw_pennylane.sh still seems to work). But it's still less than ideal.

@denialhaag made a PR for pennylane-qiskit to update: PennyLaneAI/pennylane-qiskit#719

Once that PR is merged, the changes made here should be reverted

Note: The changes in this commit were produced with AI assistance (GitHub Copilot, using various Claude models).

[burgholzer]

LGTM

[DougSO]

Thanks for this. Couple of notes:

1. The documented install path no longer works. README.md, docs/usage.md (twice) and the two install recipes in docs/recipes still say python -m pip install -r setup/requirements.txt. pip has no override option, so with qiskit==2.5.2 and pennylane-qiskit==0.45.0 it stops with ResolutionImpossible. Could you switch those five places to the uv command with --override setup/overrides.txt, the same one the cluster uses?

2. Please keep setup/overrides.txt as a file even after the pennylane-qiskit fix lands. QFw-SLURM-Cluster#73 passes --override on every build and fails when the file is missing. A file with only comments works fine with uv. Changing the last line of its header to "drop the override line, keep this file" would make that clear.

3. Optional: the override drops Qiskit's qasm3-import extra. mqt-core[qiskit] and iqm-qdmi[qiskit] ask for qiskit[qasm3-import], but an override replaces the whole requirement, so qiskit-qasm3-import and openqasm3 are no longer installed. Nothing calls qasm3.load today (QFw and the adapters only export QASM 3), so nothing breaks yet. Writing the override as qiskit[qasm3-import]==2.5.2 keeps the environment the way those packages expect.

4. Small wording fix in overrides.txt: now that pennylane-qiskit is pinned to 0.45.0, removing the override makes resolution fail outright. It no longer downgrades to 0.39.

5. Optional: no CI job installs the whole requirements.txt, which is why item 1 did not show up. A uv pip compile step over the requirements files would catch it.

[stonea]

Thanks Doug,

I've pushed some additional commits that should address your feedback. Let me know if there's anything else you'd like to see.

• (1) Switched README, usage.md (×2) and both recipes to uv pip install ... --override.
• (2) Added a paragraph at the top of overrides.txt saying not to remove the file, plus "but keep this file" in the drop-the-override note.
• (3) The override is now qiskit[qasm3-import]==2.5.2, with a comment explaining the extra.
• (4) Reworded the comment: removing the override now fails resolution outright, and the pennylane-qiskit pin should be dropped once it supports the newer Qiskit.
• (5) Added a ci-resolve job running uv pip compile --override setup/overrides.txt over the requirements files.

[DougSO]

Thanks for the updates. All five points are addressed, and the new ci-resolve job is a nice addition. One small thing left:

The five install snippets now call uv, but nothing installs it. A fresh python3 -m venv has no uv, so on a machine without uv installed system-wide the step stops with "command not found". Adding uv to the line above, python -m pip install --upgrade pip setuptools wheel uv, fixes it. The venv then has its own uv, and uv pip install installs into the active venv.

With that, it looks good to me.

[burgholzer]

Thanks for the updates. All five points are addressed, and the new ci-resolve job is a nice addition. One small thing left:

The five install snippets now call uv, but nothing installs it. A fresh python3 -m venv has no uv, so on a machine without uv installed system-wide the step stops with "command not found". Adding uv to the line above, python -m pip install --upgrade pip setuptools wheel uv, fixes it. The venv then has its own uv, and uv pip install installs into the active venv.

With that, it looks good to me.

Please do not use pip to install uv. The whole point of uv is that it is a way more modern and faster package manager and an alternative to pip.
uv has an explizit guide for how to integrate it into Docker setups, see https://docs.astral.sh/uv/guides/integration/docker/, or regular installation, see https://docs.astral.sh/uv/getting-started/installation/
If you want, I can happily take a stab at this later.

[stonea]

Thanks for the updates. All five points are addressed, and the new ci-resolve job is a nice addition. One small thing left:
The five install snippets now call uv, but nothing installs it. A fresh python3 -m venv has no uv, so on a machine without uv installed system-wide the step stops with "command not found". Adding uv to the line above, python -m pip install --upgrade pip setuptools wheel uv, fixes it. The venv then has its own uv, and uv pip install installs into the active venv.
With that, it looks good to me.

Please do not use pip to install uv. The whole point of uv is that it is a way more modern and faster package manager and an alternative to pip. uv has an explizit guide for how to integrate it into Docker setups, see https://docs.astral.sh/uv/guides/integration/docker/, or regular installation, see https://docs.astral.sh/uv/getting-started/installation/ If you want, I can happily take a stab at this later.

I don't think the instructions here necessarily relate to Docker builds. I understand once we have uv installed we should prefer using it, so maybe we should move the install of setuptools and wheel to use uv. But is there a downside to installing uv via pip? Any better way to get it into the venv? Any thoughts @DougSO?

Just to clarify what's being proposed, I pushed the instruction changes here but I'd be happy to revert it, if this is the wrong approach.

--

Also @DougSO, once I get your approval, how should I go about getting my PRs merged in QFw and QFw-SLURM-Cluster? Do you or someone else hit the final 'merge' once its ready or do I need to be added as a contributor? Of course, either way, I'd want to get my stuff reviewed. Thanks!

[denialhaag]

Any better way to get it into the venv?

Briefly chiming in here: Ideally, we use uv to set up the venv in the first place. That is, python3 -m venv "${QFW_VENV}" becomes uv venv "${QFW_VENV}". After the environment is activated as before, any python -m pip install command can be replaced by a uv pip install command. Maybe @burgholzer can give additional input tomorrow. 🙂

[burgholzer]

Any better way to get it into the venv?

Briefly chiming in here: Ideally, we use uv to set up the venv in the first place. That is, python3 -m venv "${QFW_VENV}" becomes uv venv "${QFW_VENV}". After the environment is activated as before, any python -m pip install command can be replaced by a uv pip install command. Maybe @burgholzer can give additional input tomorrow. 🙂

Yeah. There is no need to get uv "into" the venv. It should be the tool that creates it. Should simplify quite a few things across the setup.

[DougSO]

@stonea I agree with @burgholzer and @denialhaag. Installing uv with pip works, but letting uv create the venv is cleaner. Nothing in the QFw build needs pip, setuptools or wheel: setup/build-requirements.txt is only PyYAML, and the CMake build never calls pip. So the five snippets can become:

uv venv "${QFW_VENV}"
source "${QFW_VENV}/bin/activate"
uv pip install -r "${QFW_SRC}/setup/build-requirements.txt" -r "${QFW_SRC}/setup/requirements.txt" --override "${QFW_SRC}/setup/overrides.txt"

That drops the python -m pip install --upgrade ... line, so d47e47a can go. A sentence before the snippets saying to install uv first, linking https://docs.astral.sh/uv/getting-started/installation/, covers machines that don't have it.

One more line to change: README.md's Developer Testing section runs python -m pip install flake8 pytest. A venv made by uv venv has no pip, so that becomes uv pip install flake8 pytest.

On merging: you don't need write access. Once a PR is approved and CI is green, I merge it. After #170 merges, QFw-SLURM-Cluster#73 needs its QFW_REF (five places) moved from your fork commit 62a0b07 to the #170 merge commit on main. Then it can go in as well.

[stonea]

Ok cool, I agree it's simpler so long as we're fine asking users to install uv globally (which seems reasonable given how popular uv has become).

Anyway, I pushed 306feb8 which uses uv to make the venv and instructs users to install it.