Closed yurivict closed 2 years ago
I'm not exactly sure what the issue is here, Do you have a link to the freebsd port source for retworkx to see how they're bundling the source code? The python package builds fine from our source distribution release on pypi, because we bundled the retworkx-core rust crate source as part of the sdist. So I'm wondering if something is going wrong in the local copy used for the freebsd port.
That being said we also have made some changes to how the linking to the retworkx-core/rustworkx-core crate was don in: https://github.com/Qiskit/rustworkx/commit/a0aaa1f93ef21fe77dccee63cd37fdb8f43c7cee which might fix the issue too. Can you check that it fixes the issue.
The problem is gone in the current head e9edfdc.
It looks like the project was renamed into rustworkx.
Now it isn't clear how to integrate it into qiskit-terra
because it still expects retworkx.
Right, we renamed the project in https://github.com/Qiskit/rustworkx/commit/7d253cea366484d7d1b33504fe30e4775aadce85 due to a request from the maintainers of NetworkX. The way the migration is being handled is that for the rest of the 0.x.y
release series retworkx will still be published but as just a small python redirect shim. So if you import retworkx
it redirects all of the calls to rustworkx
under the covers. This should give downstream users (including qiskit) a sufficient chance to migrate. For the 1.0.0 release we're planning to drop the retworkx name from the rustworkx tree (but I plan to make the final retworkx release still just be a redirect shim that should work with any future version of rustworkx, it just won't be actively maintained). So for downstream packaging of retworkx from main (and 0.12.0 which hopefully should be released in a month or so) moving forward you can just build rustworkx as the base package (which only has a python dependency on numpy) then retworkx depends on rustworkx, and qiskit depends on retworkx.
Information