Make Transformation and NonTransformation subclass TransformationBase

[dotsdl]

In some cases it can be awkward for NonTransformation to be a subclass of Transformation, such as in alchemiscale, for cases where NonTransformation should be handled very differently.

Switching to a shared, abstract base class for Transformation and NonTransformation simplifies this.

[pep8speaks]

Hello @dotsdl! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file gufe/transformations/transformation.py:

Line 75:80: E501 line too long (80 > 79 characters)
Line 283:80: E501 line too long (80 > 79 characters)

Comment last updated at 2024-04-25 06:03:17 UTC

[IAlibay]

Thanks for opening this @dotsdl - as a first initial triage, could you possibly add in a rever rst file with a short summary of this update and any expected API breaks?

[dotsdl]

I can do that, no problem @IAlibay! I also need to fix the broken tests yet as well.

[dotsdl]

To be clear, this isn't blocking anything on alchemiscale; it's just something @ianmkenney and I noticed while working on this one: OpenFreeEnergy/alchemiscale#270

[IAlibay]

@dotsdl possibly a crazy question - does this technically change the gufe keys for transformation objects? I can't remember if it captures the parent class signatures

(partly asking because of the test failures)

[IAlibay]

The follow up question I have is if we need a 1.x gufe policy on key stability?

[dotsdl]

Will pursue a review on this from Alyssa when she starts.