Update to newest version of jeff

[denialhaag]

This PR updates to the newest version of jeff. In particular, the changes introduced by unitaryfoundation/jeff#50 and unitaryfoundation/jeff#52 are implemented.

[denialhaag]

The new Qureg type is also successfully tested in munich-quantum-toolkit/core#1637.

[burgholzer]

Thanks @denialhaag! This is great!
I just have a bunch of mostly stupid questions here; excuse the ignorance please 😌
My only real concern is that we probably should not completely abandon dynamic qubit registers. But maybe even that is fine.

[burgholzer]

This looks great now!
One question that came up in my mind: Should we also start releasing versioned tags for jeff-mlir?
Does it make sense to track the version of jeff or is there enough separate development here that a separate versioning scheme is warranted here? I am leaning towards the latter given how there is also quite a bit of conversion code from jeff to standard MLIR, which might need tweaks and patch releases.

[denialhaag]

One question that came up in my mind: Should we also start releasing versioned tags for jeff-mlir? Does it make sense to track the version of jeff or is there enough separate development here that a separate versioning scheme is warranted here? I am leaning towards the latter given how there is also quite a bit of conversion code from jeff to standard MLIR, which might need tweaks and patch releases.

I agree that it makes sense to start releasing tags and do so independently of jeff. We could tag this as v0.1.0 and then go from there. 🤔

[burgholzer]

I agree that it makes sense to start releasing tags and do so independently of jeff. We could tag this as v0.1.0 and then go from there. 🤔

That sounds good to me!
Are there any things that we still need to adjust for a 0.1.0 release?
Do we want a changelog here as well?
Do we go with a similar tagging scheme as in jeff? (jeff-mlir-v0.1.0 or just v0.1.0)

[denialhaag]

Are there any things that we still need to adjust for a 0.1.0 release?

I think the current state is good for a first version. 🤔

Do we want a changelog here as well?

I would be in favor of that! I can set this up in an immediate follow-up PR.

Do we go with a similar tagging scheme as in jeff? (jeff-mlir-v0.1.0 or just v0.1.0)

I don't have a strong opinion here. Maybe @dime10 does? 🤔

[burgholzer]

👍🏼
Let's just go with v0.1.0 here. I think the <prefix>-version format is only really beneficial whenever a repository releases multiple subcomponents that might be versioned differently. This should not be the case here.

I'll go ahead and merge this for now.

[dime10]

I don't have a strong opinion here. Maybe @dime10 does? 🤔

All good, thanks for updating these 🙏

This PR does make me wonder whether we want to check in all those test cases if they are auto-generated anyway, but I suppose checking them is reliable no matter what.

[denialhaag]

This PR does make me wonder whether we want to check in all those test cases if they are auto-generated anyway, but I suppose checking them is reliable no matter what.

That's a good point! To make this feasible, we should probably release a first version of jeff-format on PyPI. The setup of the Python environment could be a bit ugly otherwise. 🤔

[burgholzer]

This PR does make me wonder whether we want to check in all those test cases if they are auto-generated anyway, but I suppose checking them is reliable no matter what.

That's a good point! To make this feasible, we should probably release a first version of jeff-format on PyPI. The setup of the Python environment could be a bit ugly otherwise. 🤔

Yeah, especially given how one can't inspect them as part of a diff on GitHub anyway.
I had thought that we already had a release pipeline for the Python package of jeff, but that was apparently just in my head. Would definitely make sense to create a release/CD pipeline for that and publish the respective package.

[denialhaag]

This PR does make me wonder whether we want to check in all those test cases if they are auto-generated anyway, but I suppose checking them is reliable no matter what.

That's a good point! To make this feasible, we should probably release a first version of jeff-format on PyPI. The setup of the Python environment could be a bit ugly otherwise. 🤔

Yeah, especially given how one can't inspect them as part of a diff on GitHub anyway. I had thought that we already had a release pipeline for the Python package of jeff, but that was apparently just in my head. Would definitely make sense to create a release/CD pipeline for that and publish the respective package.

There's something else I've been ignoring so far: For some reason, the output of jeff-format is not perfectly reproducible. In particular, all test cases with two functions can change when generate_test_cases.py is rerun. If that happens, the created jeff module is faulty. Because the order of the functions has changed, the main function is suddenly trying to call itself. I can create a minimal example tomorrow and create an issue in the jeff repository so that we can find a solution to this.