Developer Guide — SatNOGS Network 1.118 documentation

# Developer Guide

Thank you for your interest in developing SatNOGS! There are always bugs to file; bugs to fix in code; improvements to be made to the documentation; and more.

The below instructions are for software developers who want to work on satnogs-network code.

## Workflow

When you want to start developing for SatNOGS, you should follow the installation instructions, then…

1. Read CONTRIBUTING.md file carefully.

2. Fork the upstream repository in GitLab.

3. Code!

4. Test the changes by Running the tests locally and fix any errors.

5. Commit changes to the code!

6. When you’re done, push your changes to your fork.

7. Issue a merge request on Gitlab.

8. Wait to hear from one of the core developers.

If you’re asked to change your commit message or code, you can amend or rebase and then force push.

If you need more Git expertise, a good resource is the Git book.

## Templates

satnogs-network uses Django’s template engine templates.

## Frontend development

Third-party static assets are not included in this repository. The frontend dependencies are managed with `npm`. Development tasks like the copying of assets, code linting and tests are managed with `gulp`.

To download third-party static assets:

1. Install dependencies with `npm`:

       npm install

2. Test and copy the newly downlodaded static assets:

       ./node_modules/.bin/gulp

To add new or remove existing third-party static assets:

1. Install a new dependency:

       npm install <package>

2. Uninstall an existing dependency:

       npm uninstall <package>

3. Copy the newly downlodaded static assets:

       ./node_modules/.bin/gulp assets

## Backend development

When running satnogs-network using the docker container the webserver auto-reloads when files get changed. You need to restart the network-web container only when you change something in settings.py. All the other changes are directly applied with refreshing the page you are currently working on.

## Simulating station heartbeats

Only stations which have been seen by the server in the last hour (by default, can be customized by STATION_HEARTBEAT_TIME) are taken into consideration when scheduling observations. In order to simulate an heartbeat of the stations 7, 23 and 42, the following command can be used:

    docker-compose exec web django-admin update_station_last_seen 7 23 42

## Manually run a celery tasks

The following procedure can be used to manually run celery tasks in the local development environment:

1. Install the docker-based development environment.

2. Start a django-admin shell:

       docker-compose exec web django-admin shell

3. Run an asnyc task and check if it succeeded:

       from network.base.tasks import update_all_tle
       task = update_all_tle.delay()
       assert(task.ready())

4. (optional) Check the celery log for the task output:

       docker-compose logs celery

## Running the tests locally

To test your changes to the code locally with tox in the same way the CI does you can follow these steps:

1. Setup a new virtual environment (this shouldn’t be the same virtual environment you might have created for the VirtualEnv Installation):

       mkvirtualenv network-test -a .

2. Install tox in the same version defined by `GITLAB_CI_PYPI_TOX` in .gitlab-ci.yml:

       pip install tox~=3.8.0

3. Run the tests:

       tox -e "flake8,isort,yapf,pylint"

## Coding Style

Follow the PEP8 and PEP257 Style Guides.

## What to work on

You can check open issues. We regurarly open issues for tracking new features. You pick one and start coding.