@sbillinge PR ready for review. After this I will pin this commit as submodule on the diffpy.srreal end and we shall pass ci.

Do we want to merge migration-nano here into main? Even if we are not releasing I still think we should build from the latest default branch

Do we want to merge migration-nano here into main? Even if we are not releasing I still think we should build from the latest default branch

Yes sure please. I have diffpy.srreal ready and I'll pin this commit after you merge.

I did some more reading and for our case I don't really see the advantage of vendoring libdiffpy vs. Releasing it. Why are we doing this?

I did some more reading and for our case I don't really see the advantage of vendoring libdiffpy vs. Releasing it. Why are we doing this?

I believe this was inspired by the migration from the pyobjcryst side. (see diffpy/diffpy.srreal#90)

Right, so what was the inspiration? Why did they do it and what advantages come from that? I suggest we stick with the current scheme for this release and do a proper release of libdiffpy and keep it as a dependency. If there are compelling reasons to do it the other way we can move to that for the next release. I assumed that there were significant advantages that were suddenly made possible by the switch to nanobind that we didn't have before and that that was why Vincent had decided to switch, and so I wanted to trigger a conversation to understand the pros and cons.

Actions:

1. finish a release of libdiffpy
2. revert srreal changes back so it releases with libdiffy as a dependency
3. Maybe arrange a call with everyone, possibly including Vincent to discuss this, but arrrive at that meeting with as much knowledge as possible about what this change brings us and why it is suddenly possible now. Also anything else that is made possible by the nanobind switch that we can take advantage of in principle.

There is no rush for (3)

Right, so what was the inspiration? Why did they do it and what advantages come from that? I suggest we stick with the current scheme for this release and do a proper release of libdiffpy and keep it as a dependency. If there are compelling reasons to do it the other way we can move to that for the next release. I assumed that there were significant advantages that were suddenly made possible by the switch to nanobind that we didn't have before and that that was why Vincent had decided to switch, and so I wanted to trigger a conversation to understand the pros and cons.

Actions:

1. finish a release of libdiffpy
2. revert srreal changes back so it releases with libdiffy as a dependency
3. Maybe arrange a call with everyone, possibly including Vincent to discuss this, but arrrive at that meeting with as much knowledge as possible about what this change brings us and why it is suddenly possible now. Also anything else that is made possible by the nanobind switch that we can take advantage of in principle.

There is no rush for (3)

Understood. I will handle the diffpy.srreal side.