Creating GMML2 from GMML1 rationale and approach.
GMML1 was essentially two designs living together. The new and old “Central Data Structure” design. What became GMML2 was created in the gmml/CentralDataStructure folder as a replacement for the ideas used when making the original Assembly, Ensemble, Residue etc classes. Initially they used some common files, but that dependency caused nightmares so I cloned functionality until I got to the point that they were independent. The idea was for GMML2 to eventually replace GMML1, but the timeline for that is taking way too long, and we are suffering as a result because compile times are insane, and tooling breaks/is nuts to use on GMML1.
The following webtools/functionality rely on the new CDS:
Glycoprotein builder, pdbPreprocessor/MDPrep (two names), all carbohydrate builders.
The following webtools/functionality rely on old CDS:
Glyfinder, Glycomimetic.
I want to split out GMML2 from GMML1 in three phases.
Phase 1: Fork GMML2: (underway from January 24):
Fork GMML2 from GMML and delete everything that isn’t the new Central Data Structure (CDS). We will work on GMML2 in peace, but this phase should ideally end quickly. Changes to GMML1 can be synced into GMML2. Changes from GMML2 cannot go into GMML1 without a lot of care, and I don’t have a good workflow for that. i.e. this is not cool.
Phase 2: Activate GMML2: requires that we can create a separate gmml2 swig file in gems, and have gems use it. The dev env must also know about gmml2 and compile it. Website deployment scripts likely need to be aware of this split too so the use the correct repo.
Phase 3: Deprecate GMML1. Requires that we have replaced all the functionality in Gmml1 that allows for glyfinder and glycomimetics.
