⬆️🔒️ Lock file maintenance

[renovate]

This PR contains the following updates:

Update	Change
lockFileMaintenance	All locks refreshed

🔧 This Pull Request updates lock files to use the latest dependency versions.

---

Configuration

📅 Schedule: Branch creation - "before 4am on monday" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[denialhaag]

@burgholzer, I'm a bit confused here... I already replaced the profiles, and the tests pass for me locally. 🤔

[burgholzer]

@burgholzer, I'm a bit confused here... I already replaced the profiles, and the tests pass for me locally. 🤔

That is definitely not the only strange thing here..
For some reason, the Python tests are all fetching MQT Core via FetchContent (https://github.com/munich-quantum-toolkit/qcec/actions/runs/18321885866/job/52177392611?pr=720#step:8:14427) although it should be available from the build time dependency to the Python package, which is also found according to the logs.
Something is broken here (and potentially in other repos that depend on MQT Core).

[denialhaag]

Huh... I'll have a look at this tomorrow!

[burgholzer]

Huh... I'll have a look at this tomorrow!

I dug a little bit into this and this seems to have to do with something that we did to the nlohmann_json dependency over the last couple of releases.
For some reason, it is no longer part of the wheel distribution while it was previously.

If one includes a find_package(mqt-core REQUIRED) call before the FetchContent directive in cmake/ExternalDependencies, one gets a proper error message that is probably swallowed by the FetchContent/find_package integration:

      [stderr]
      fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: can't figure out the architecture type of: /Users/burgholzer/.local/bin/cmake
      CMake Error at /Users/burgholzer/.local/share/uv/tools/cmake/lib/python3.10/site-packages/cmake/data/share/cmake-3.31/Modules/CMakeFindDependencyMacro.cmake:76 (find_package):
        By not providing "Findnlohmann_json.cmake" in CMAKE_MODULE_PATH this
        project has asked CMake to find a package configuration file provided by
        "nlohmann_json", but CMake did not find one.

        Could not find a package configuration file provided by "nlohmann_json"
        with any of the following names:

          nlohmann_jsonConfig.cmake
          nlohmann_json-config.cmake

        Add the installation prefix of "nlohmann_json" to CMAKE_PREFIX_PATH or set
        "nlohmann_json_DIR" to a directory containing one of the above files.  If
        "nlohmann_json" provides a separate development package or SDK, be sure it
        has been installed.
      Call Stack (most recent call first):
        /Users/burgholzer/.cache/uv/builds-v0/.tmpOmKl5v/lib/python3.12/site-packages/mqt/core/share/cmake/mqt-core/mqt-core-config.cmake:23 (find_dependency)
        cmake/ExternalDependencies.cmake:53 (find_package)
        CMakeLists.txt:55 (include)



      *** CMake configuration failed

      hint: This usually indicates a problem with the package or the build environment.

This indicates that the config script is looking for nlohmann_json, which is a public dependency for some of our libraries that we ship with mqt-core, but cannot find it.

[burgholzer]

Okay, a little more info:
The culprit is munich-quantum-toolkit/core#1021, which explicitly set the install components and, in the process, removed the install of nlohmann_json.
This was released as part of mqt-core v3.1.0 and exists since then 😅 v3.0.2 should be unaffected.

However, all of that is independent from the error here I suppose. For me, the tests here pass as well. I can check on Thursday on my Linux machine, whether I can reproduce the failures.

[denialhaag]

I have now created the profiles in an Ubuntu Docker container. The CI should be green now, but now the tests are failing for me locally, of course. 🙃

[denialhaag]

Now that the mqt-core issue is fixed, this can go in, I'd say.

The only problem I do see is that the profile tests will fail on macOS systems. I can change the tests to be skipped on non-Linux systems. What do you think, @burgholzer?

[burgholzer]

Now that the mqt-core issue is fixed, this can go in, I'd say.

The only problem I do see is that the profile tests will fail on macOS systems. I can change the tests to be skipped on non-Linux systems. What do you think, @burgholzer?

Hm. Previously, these tests were deterministic on all systems if I remember correctly. I don't see an obvious reason why that should have changed. Can we investigate the cause for this so that we better understand if this is expected behavior or whether something is broken here?

[denialhaag]

Okay, I think I found the issue.

On macOS, the script below prints 5. On Linux (tested using a python:3.12 Docker image), it prints 10.

from qiskit import QuantumCircuit, transpile
import numpy as np

qc = QuantumCircuit(2)
rng = np.random.default_rng(seed=12345)
param = rng.uniform(-np.pi, np.pi)
qc.cp(param, 0, 1)
print(len(transpile(qc, basis_gates=["id", "rz", "sx", "x", "cx"], optimization_level=2, seed_transpiler=12345)))

Judging by 973ae0f, this platform dependence of transpile() seems to be restricted to p, s, sdg, t, and tdg gates with one control qubit (at least for our test cases).

Should I bring this up with the Qiskit devs? 🤔

[burgholzer]

Okay, I think I found the issue.

On macOS, the script below prints 5. On Linux (tested using a python:3.12 Docker image), it prints 10.

from qiskit import QuantumCircuit, transpile
import numpy as np

qc = QuantumCircuit(2)
rng = np.random.default_rng(seed=12345)
param = rng.uniform(-np.pi, np.pi)
qc.cp(param, 0, 1)
print(len(transpile(qc, basis_gates=["id", "rz", "sx", "x", "cx"], optimization_level=2, seed_transpiler=12345)))

Judging by 973ae0f, this platform dependence of transpile() seems to be restricted to p, s, sdg, t, and tdg gates with one control qubit (at least for our test cases).

Should I bring this up with the Qiskit devs? 🤔

This might actually be a numpy thing.
What's the value of param printed on macOS?
My linux system produces -1.7131982974314244.
Rotation gates with different angles may have different costs.
Maybe it would be more robust for us to take fixed numbers for the parameters.

[denialhaag]

I tried around a bit now, and it does seem to be a numpy issue (although the printed param is the same on macOS).

I have switched to integer parameters now, and the tests are passing on Linux and macOS. 👍

[burgholzer]

This looks reasonable now. Let's get this in

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!