Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
You can contribute in many ways:
Types of Contributions¶
Report bugs at https://github.com/biosustain/cameo/issues.
If you are reporting a bug, please include:
Your operating system name and version.
Any details about your local setup that might be helpful in troubleshooting.
Detailed steps to reproduce the bug.
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.
cameo could always use more documentation, whether as part of the official cameo docs, in docstrings, or even on the web in blog posts, articles, and such - all contributions are welcome!
The best way to send feedback is to file an issue at https://github.com/biosustain/cameo/issues.
If you are proposing a feature:
Explain in detail how it would work.
Keep the scope as narrow as possible, to make it easier to implement.
Remember that this is a volunteer-driven project, and that contributions are welcome :)
Want to contribute a new feature or improvement? Consider starting by raising an issue and assign it to yourself to describe what you want to achieve. This way, we reduce the risk of duplicated efforts and you may also get suggestions on how to best proceed, e.g. there may be half-finished work in some branch that you could start with.
Here’s how to set up
cameo for local development.
cameorepository on GitHub.
Clone your fork locally:
git clone email@example.com:your_name_here/cameo.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 cameo cd cameo/ python setup.py develop
Create a branch for local development:
git checkout -b name-of-your-bugfix-or-feature
Now you can make your changes locally.
When you are done making changes, check that your changes pass flake8 and the tests, including testing other Python versions with tox:
tox -e py35
To only test on python 3.5 (tox on all python versions takes quite long so may want to try one at a time to start with. To get flake8 and tox, just pip install them into your virtualenv.
Commit your changes and push your branch to GitHub:
git add . git commit -m "Your detailed description of your changes." git push origin name-of-your-bugfix-or-feature
Submit a pull request through the GitHub website.
Pull Request Guidelines¶
Before you submit a pull request, check that it meets these guidelines:
The pull request should include tests. Except in very rare circumstances, code coverage must not decrease (as reported by codecov which runs automatically when you submit your pull request)
If the pull request adds functionality, the docs should be updated. Put your new functionality into a function with a docstring and consider creating a notebook that demonstrates the usage in
The pull request should work for Python 2.7, 3.4 and 3.5. Check https://travis-ci.org/biosustain/cameo/pull_requests and make sure that the tests pass for all supported Python versions.
Assign a reviewer to your pull request. If in doubt, assign Niko Sonnenschein. Your pull request must be approved by all reviewers before it can be merged.
Branching model and non-free dependencies¶
At its core, cameo is a package for using mixed linear integer programming (MILP) techniques to support metabolic
engineering / strain design. However, cameo does not implement the algorithms that actually solve these problems, rather
it makes use of third-party libraries to do this after the problems have been carefully formulated to be possible to
feed to these general solvers. For certain problems, some solvers are better than others and not all of these are
available under free/libre licenses. Unit test in cameo that have non-free dependencies are not run during continuous
integration for the
devel branch to enable pull requests (which cannot have access to these dependencies). The
branching model we use therefore looks like this
Is the branch all pull-requests from non-maintainers should be based on and that does not run unit tests with non-free dependencies.
Is only touched by maintainers and used to also run unit tests with non-free dependencies. It therefore has a higher code coverage than
Is only touched by maintainers and is the branch with only tested, reviewed code that is released or ready for the next release.