Closed edkerk closed 3 years ago
One concern with the current implementation of the curation script is that it is inconvenient to test the v_1_3_0.py since it needs the model version 1.2.0 to run. And currently, the model version in the repository is not 1.2.0. Not sure how we should solve this. We could of course save intermediate model versions in an archive that can be used as input? What do you think?
True. Another strategy would be to have a v1_3_0.py
script that gathers the various curations, while having the individual scripts (each referring to one Issue?) in a subfolder. Then, v1_3_0.py
could be coded to check that the model "input" is the previous model version (or could even specifically load that release using git), before running all individual scripts and finally generating all output.
I think it would be too many files if we strictly have one file per issue. Hower, on a higher level your suggestion might work. E.g. A general reconstruction scipt that checks model version before it calls v_1_3_0.py.
Actually, I think it would be nice to bring this discussion up in the Standard-GEM development, as I am sure this is not a concern that is limited to the Sco-GEM development. What do you think?
I guess this is partially overlapping with https://github.com/MetabolicAtlas/standard-GEM/issues/20
It is indeed a universal issue, discussion in standard-GEM
would make sense.
One script per issue might indeed be too much, perhaps multiple smaller issues could be combined in a script e.g. v1_3_0/misc_curations.py
script, while larger issues could have their own dedicated script e.g. v1_3_0/feat_reassign_all_metabolite_annotations.py
.
One issue I can see is that the model version number will not be known until PR to master
, so instead of v1_3_0/
this folder could be named latest/
, and renamed to the desired version number in devel
before making PR to master
. However, if these paths are also hard-coded in any scripts, then that would also have to be changed.
Easiest way is then not to name scripts by their version number or collect them in folders named with version number. Instead, the functions and data are in appropriate subfolders of code/
and data/
(for instance ../biomass/
or ../reversibility/
, while still having a collecting script v1_3_0.py
that checks model version before calling the appropriate functions.
I still think that it might make sense to have a model/archive
folder. A pull reuqest from devel to master that cause a minor bup in version could archive the xml-version of that model. Thus, in the model
folder you can always find the latest model version, but if you need the previous version for testing you can easily do that.
- [x] Rerun the memote tests (including the custom growth / knockout phenotypes test) and assure that the accuracy is the same
- [x] Update memote report
Will include code that runs Memote locally with each release.
Main improvements in this PR:
fix:
<notes>
entries, with information already covered elsewhereexport.py
recognizessbo
terms, adheres to standard-GEM, include subroutine to load previous releases of the model (export.get_earlier_model_unversioned
)feat:
increaseVersion.py
function that should be run on master branch to prepare a new version release (closes #133)code/curation/vx_x_x.py
refactor:
xml
andyml
for now) are located in themodel/
folder (closes #110)code/sulheim2020/
, reducing the packages in/requirements.txt
doc:
.github
folder (closes #133)chore:
I hereby confirm that I have:
devel
as a target branch (top left drop-down menu)