Move ligand utils to gufe

[atravitz]

partially addresses #560, along with OpenFreeEnergy/gufe#602

Checklist

• Added a news entry

Developers certificate of origin

• I certify that this contribution is covered by the MIT License here and the Developer Certificate of Origin at https://developercertificate.org/.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.37%. Comparing base (d0af3f5) to head (f9c1688).
⚠️ Report is 98 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1479      +/-   ##
==========================================
- Coverage   95.23%   92.37%   -2.87%     
==========================================
  Files         165      165              
  Lines       12640    12640              
==========================================
- Hits        12038    11676     -362     
- Misses        602      964     +362     

Flag	Coverage Δ
fast-tests	92.37% <100.00%> (?)
slow-tests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mikemhenry]

This looks good -- it will require us to pin to the version of gufe we release with LigandAtomMapping.get_alchemical_charge_difference() I will approve this BUT something to maybe consider is we keep the deprecation warning in for a release before we require an update to the latest gufe.

P.S. This argument only holds water if there is some reason a user wouldn't want to update to the latest gufe, AFAIK there isn't any new deps or major changes that warrant this so I believe it is a moot point

[atravitz]

This looks good -- it will require us to pin to the version of gufe we release with LigandAtomMapping.get_alchemical_charge_difference() I will approve this BUT something to maybe consider is we keep the deprecation warning in for a release before we require an update to the latest gufe.

P.S. This argument only holds water if there is some reason a user wouldn't want to update to the latest gufe, AFAIK there isn't any new deps or major changes that warrant this so I believe it is a moot point

I agree - if this were moving to any package other than gufe, I would do a deprecation cycle before moving the code. But since gufe and openfe are closely tied and we make releases together, I think this is fine.

[github-actions]

No API break detected ✅