Our goal in promoting this tool is to achieve two major shifts in the metabolic model building community:
The memote tool therefore performs four subfunctions:
And in order to make this process as easy as possible the generated repository can easily be integrated with continuous integration testing providers such as Travis CI, which means that anytime you push a model change to GitHub, the test suite will be run automatically and a report will be available for you to look at via GitHub pages for your repository.
For comments and questions get in touch via
Are you excited about this project? Consider contributing by adding novel tests, reporting or fixing bugs, and generally help us make this a better software for everyone.
We highly recommend creating a Python virtualenv for your model testing purposes.
To install memote, run this command in your terminal:
$ pip install memote
This is the preferred method to install memote, as it will always install the most recent stable release.
If you don’t have pip installed, this Python installation guide can guide you through the process.
The sources for memote can be downloaded from the Github repo.
You can either clone the public repository:
$ git clone https://github.com/opencobra/memote.git
Or download the tarball or zip archive:
$ curl -OL https://github.com/opencobra/memote/archive/master.zip
Once you have a copy of the source files, you can install it with:
$ pip install .
After installation, memote can be employed in two different ways: As a benchmarking tool for ad hoc model assessment and as an automated testing suite to aid with the reconstruction of metabolic models. When using memote to benchmark a model, the tests are run once and a report is generated which describes the status-quo. As an automated testing suite, memote facilitates tracking incremental model changes in a version controlled repository and can enable continuous testing and reporting if desired.
Here, we explain step-by-step the necessary commands to pursue either workflow. Users that have already followed this tutorial once may want to refer to the cheat-sheet flowchart to refresh their memory.
To benchmark the performance of a single model, run this command in your terminal:
$ memote --model path/to/model.xml report --one-time
This will generate the performance report as index.html
.
The output filename can be changed by adding the following option.
To illustrate here it is changed to report.html
.
$ memote --model path/to/model.xml --filename "report.html" report --one-time
This functionality is coming soon.
Comparing two models against each other and quickly identify the differences.
When starting a memote repository, users need to provide an SBMLv3-FBC formatted file. Automatic draft reconstruction tools such as Pathway Tools, Model SEED, The RAVEN Toolbox and others are able to output files in this format. Model repositories such as BiGG or BioModels further serve as a great resource for models in the correct format.
With this in mind, starting a local, version-controlled model repository is as simple as running the following command:
$ memote new
After this, the user will be prompted with a few questions regarding details of the project. If the project is to be kept strictly locally, the user does not need to supply GitHub (or GitLab - not implemented yet) credentials. However, these are a requirement if the project is to use the full benefits of distributed version control such as cloud-based development, remote collaboration and community feedback. It is important to note that furthermore a public repository is needed to set up automatic testing through continuous integration, one of the key features of memote.
Once all the questions following memote new
have been answered, a public
repository has been created under either the user’s GitHub or GitLab account.
To enable continuous integration via Travis CI the following command is
executed:
This functionality is coming soon. A manual workaround is outlined in the cookiecutter-memote readme.
$ memote online
Now, after each edit to the model in the repository, the user can generate an update to the continuous model report shown at the project’s gh-pages branch by saving the changes with the following command:
This functionality is coming soon, for now please utilize the steps outlined for advanced users.
$ memote save
For advanced users: memote save
is the equivalent of executing git add .
,
git commit
and git push
in sequence.
Users that have decided to not to use GitHub (or GitLab Not implemented yet) or those that have decided to set the model repository to private, will need to execute:
$ memote
to run the testing suite on their commit history followed by:
$ memote report
to generate the same type of report that would be shown automatically with
continuous integration. After this it is crucial to save the generated test
results by running memote save
again.
We recommend the public workflow not only to promote open, collaborative science but also to benefit from the full functionality of memote.
This cheat-sheet flowchart servers as a visual guide on how to get up and running with memote! It is essentially the pictographic form of the section Getting Started.
Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
You can contribute in many ways:
Report bugs at https://github.com/opencobra/memote/issues.
If you are reporting a bug, please include:
Look through the GitHub issues for bugs. Anything tagged with “bug” and “help wanted” is open to whoever wants to implement it.
Look through the GitHub issues for features. Anything tagged with “enhancement” and “help wanted” is open to whoever wants to implement it.
memote could always use more documentation, whether as part of the official memote docs, in docstrings, or even on the web in blog posts, articles, and such.
The best way to send feedback is to file an issue at https://github.com/opencobra/memote/issues.
If you are proposing a feature:
Ready to contribute? Here’s how to set up memote for local development.
Fork the memote repo on GitHub.
Clone your fork locally:
git clone git@github.com:your_name_here/memote.git
Install your local copy into a virtualenv. Assuming you have virtualenvwrapper installed, this is how you set up your fork for local development:
mkvirtualenv memote
cd memote/
pip install -e .
Create a branch for local development using fix
or feat
as a prefix:
git checkout -b fix-name-of-your-bugfix
Now you can make your changes locally.
When you’re done making changes, check that your changes pass flake8 and the tests, including testing other Python versions. This is all included with tox:
tox
You can run all tests in parallel using detox. To get tox and detox, just pip install them into your virtualenv.
Commit your changes and push your branch to GitHub. Please use semantic commit messages:
git add .
git commit -m "fix: Your detailed description of your changes."
git push origin fix-name-of-your-bugfix
Submit a pull request through the GitHub website.
Before you submit a pull request, check that it meets these guidelines:
memote online
.memote.suite.api
(#162).memote
(#172).memote online
(#95, #153).memote.show_versions()
for easy dependency checking.