If you are thinking about making Mopidy better, or you just want to hack on it, that’s great. Here are some tips to get you started.
Clone your fork on GitHub to your computer.
Consider making a Python virtualenv for Mopidy development to wall of Mopidy and it’s dependencies from the rest of your system. If you do so, create the virtualenv with the
--system-site-packagesflag so that Mopidy can use globally installed dependencies like GStreamer. If you don’t use a virtualenv, you may need to run the following
python setup.pycommands with
sudoto install stuff globally on your computer.
Install dependencies as described in the Installation section.
Install additional development dependencies:
pip install -r dev-requirements.txt
Checkout a new branch (usually based on
develop) and name it accordingly to what you intend to do.
- Features get the prefix
- Bug fixes get the prefix
- Improvements to the documentation get the prefix
- Features get the prefix
Running Mopidy from Git¶
If you want to hack on Mopidy, you should run Mopidy directly from the Git repo.
Go to the Git repo root:
To get a
mopidyexecutable and register all bundled extensions with setuptools, run:
python setup.py develop
It still works to run
python mopidydirectly on the
mopidyPython package directory, but if you have never run
python setup.py developthe extensions bundled with Mopidy isn’t registered with setuptools, so Mopidy will start without any frontends or backends, making it quite useless.
Now you can run the Mopidy command, and it will run using the code in the Git repo:
If you do any changes to the code, you’ll just need to restart
mopidyto see the changes take effect.
Mopidy has quite good test coverage, and we would like all new code going into Mopidy to come with tests.
To run all tests, go to the project directory and run:
To run tests with test coverage statistics:
Test coverage statistics can also be viewed online at coveralls.io.
Always check the code for errors and style issues using flake8:
If successful, the command will not print anything at all.
Finally, there is the ultimate but a bit slower command. To run both tests, docs build, and flake8 linting, run:
This will run exactly the same tests as Travis CI runs for all our branches and pull requests. If this command turns green, you can be quite confident that your pull request will get the green flag from Travis as well, which is a requirement for it to be merged.
- One branch per feature or fix. Keep branches small and on topic.
- Follow the code style, especially make sure
flake8does not complain about anything.
- Write good commit messages. Here’s three blog posts on how to do it right:
- Send a pull request to the
developbranch. See the GitHub pull request docs for help.