fix: annotations and minor reaction curations

[edkerk]

Main improvements in this PR:

• fix
  • correct biocyc annotation ZCAROTDH2 (closes #33)
  • correct invalid KEGG metabolite IDs identified in Sco4 paper (closes #62)
  • directionality of ICDHyr (closes #87)
  • directionality of ferredoxin-NAPD reductase (closes #90)
  • curated duplicated reactions, involved GABTA, ABPYRATA, CA2abc1 and AMEt (closes #104)
  • correct and deprecate multiple reaction and metabolite annotations (closes #105)
  • remove reaction GND2, wrong co-factor (closes #106)
  • remove multiple annotations when only one is correct (KEGG, ec-code) (closes #111)

I hereby confirm that I have:

• [x] Tested my code with all requirements for running the model
• [X] Selected devel as a target branch (top left drop-down menu)

[sulheim]

Great work! Should curate/v130.py be called in reconstruct_ScoGEM.py, or how do you plan to move forward when later updates are introduced? Does this PR close #111, #62, #104 and #106?

[edkerk]

@sulheim Instead of one script generating the latest Sco-GEM version from scratch, it's probably more convenient to have scripts to update from one release to the next. In the future there might be changes in software that would break the earlier scripts (perhaps not seriously, but requiring changes anyway), so pretending that the model can always be regenerated completely from iKS1317, Sco4 and the other one would just take more work.

Now I've coded all changes in v130.py, but it could also function as "reconstruct_ScoGEM.py" for each release by combining separate scripts with changes. However, each release is likely to have much less changes then the massive work to reconstruct Sco-GEM.

Note that I'll make a few more commits to this PR, regarding #105 and documentation of v130.py (could also be named differently?). And yes, it closes a bunch of issues, will modify the PR message to automate.

[edkerk]

One issue I've noticed is that export.py is in /code while further (curation) scripts would be in child folders, which means that export.py cannot easily be imported in those scripts. As a workaround, we could have a latest_changes.py placeholder script in /code, which calls the latest update script (/code/curate/v130.py in this case) and then runs export, and this placeholder script should be updated after each release to refer to the latest update script.

Or any other solution?

[sulheim]

I think your suggestion makes sense. Otherwise, one could always add the parent folder to path with sys.path.append(".."), but I think your suggestion is better. We could potentially add version number to the model id in the xml-file (so the latest_changes.py) don't run v130.py if the model already has those curations. Anyway, the final solution should be stated in the README

[sulheim]

By the way. should we add the GitHub discussion feature (and possibly discard the gitter repo)?