gufe: Network Planning Stage - make this part ready for new methods.

[RiesBen]

This PR is mainly motifvated by #342 (pls. read this issue too ;) ).

The idea of the draft is to make gufe future ready for future developments and to indictate the power of certain approaches as they are more general than currently indicated by the Types we use.

Example:

so network planners are not really dependent on LigandAtomMappings, but ComponentMappings, that could be any type of component. Currently we are limiting the signatures to the RBFE Small Molecules. With this PR, we make it possible to show the generality of approaches

My train of thought follows in general the Setup Pipeline that we defined back in the day, but a bit more abstract than in the following Ligand-RBFE workflow. With these changes we get setup ready for e.g. ProteinMutations and SepTop.

Note:

• This PR was discussed in the protocol dev round.
• Changes are only in setup, rest is just refactoring.

Principles:

• Changes should not be API-breaking.

Additional Thoughts:

• A ChemicalSystem could be interpreted as a collection of Components and therefore this should be reflected in the definitions.

[pep8speaks]

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

• In the file gufe/__init__.py:

Line 34:80: E501 line too long (86 > 79 characters)

• In the file gufe/setup/alchemical_network_planner.py:

Line 11:80: E501 line too long (82 > 79 characters)

• In the file gufe/setup/chemical_system_generator.py:

Line 11:1: E302 expected 2 blank lines, found 1
Line 20:80: E501 line too long (81 > 79 characters)
Line 25:36: W292 no newline at end of file

• In the file gufe/setup/network_planning/atom_mapping_based/atom_mapper.py:

Line 31:1: W391 blank line at end of file

• In the file gufe/setup/network_planning/atom_mapping_based/atom_mapping.py:

Line 59:1: W391 blank line at end of file

• In the file gufe/setup/network_planning/atom_mapping_based/atom_mapping_scorer.py:

Line 28:80: E501 line too long (136 > 79 characters)
Line 40:80: E501 line too long (89 > 79 characters)

• In the file gufe/setup/network_planning/atom_mapping_based/ligandnetwork.py:

Line 15:80: E501 line too long (96 > 79 characters)
Line 281:12: W292 no newline at end of file
Line 281:12: W292 no newline at end of file
Line 281:12: W292 no newline at end of file

• In the file gufe/setup/network_planning/component_mapping.py:

Line 20:80: E501 line too long (109 > 79 characters)

• In the file gufe/setup/network_planning/component_mapping_scorer.py:

Line 7:5: E271 multiple spaces after keyword
Line 9:1: E302 expected 2 blank lines, found 1
Line 24:80: E501 line too long (111 > 79 characters)
Line 34:80: E501 line too long (89 > 79 characters)

• In the file gufe/setup/network_planning/network_plan.py:

Line 16:1: E302 expected 2 blank lines, found 1
Line 127:31: E127 continuation line over-indented for visual indent
Line 188:80: E501 line too long (80 > 79 characters)

• In the file gufe/setup/network_planning/network_planner.py:

Line 12:1: E302 expected 2 blank lines, found 1
Line 19:55: E231 missing whitespace after ':'
Line 19:80: E501 line too long (95 > 79 characters)
Line 20:80: E501 line too long (97 > 79 characters)
Line 29:22: E222 multiple spaces after operator
Line 32:5: E303 too many blank lines (2)
Line 32:40: E225 missing whitespace around operator
Line 36:80: E501 line too long (94 > 79 characters)
Line 36:81: E225 missing whitespace around operator

Comment last updated at 2024-09-18 08:20:34 UTC

[dotsdl]

@RiesBen please let me know when you'd like a review from me! Happy to help you get this into gufe!

[IAlibay]

Similarly, this can't go away until 2.0

[RiesBen]

hm would it make sense to split this out into a new PR, or drop it completly? I m not sure of your intend here.

[IAlibay]

The intent of this comment is solely "API breaks can't happen until 2.0 and this is an API break".

As for the other things, I would suggest keeping a PR that sticks to changes that we had agreed upon and then doing a separate PR for any other extras.

[RiesBen]

I think now it should be not api breaking.

[dotsdl]

@RiesBen can you offer a response to @IAlibay above? Can you give us a checklist of things you aim to do before you declare this PR ready for review?

[RiesBen]

@RiesBen can you offer a response to @IAlibay above? Can you give us a checklist of things you aim to do before you declare this PR ready for review?

Sure :)
I think the current ToDo List is the following:

• discuss change suggestions in order to find a clear direction with some changes
  • RFEComponentLabels Labels for ChemicalSystems transfer them from OpenFE to here or not?
  • NetworkPlan name improvement
  • How to proceed with code/import structure. my suggestion, make them not API breaking
• adapt the PR to the discussions.
• Check and adapt unit test
  • AtomMappingScorer
  • ComponentMappingScorer
  • ComponentMapper
  • NetworkPlan
  • Network_planner
    --> after this ready to merge :)

[RiesBen]

Current CI-Failures reasons are 2 tests:

1. Gufe key stability: the key for LigandNetwork and LigandAtomMapping is not equal to the expected GufeKey. (affects: test_key_stable, test_repr
2. test_graph_annotations: The Annotations of the LigandAtomMapping is lost, after testing found this to have some weird behavior when you call ligand_network.edges and `ligand_network.graph..