Developing in RASCIL

Use the SKA Python Coding Guidelines (

We recommend using a tool to help ensure PEP 8 compliance. PyCharm does a good job at this and other code quality checks.


  • Use git to make a local clone of the Github respository:

    git clone
  • Make a branch. Use a descriptive name e.g. abc-123-feature_improved_gridding, abc-1231-bugfix_issue_666 (Note that the branch name has to start with a Jira ticket ID)

  • Make whatever changes are needed, including documentation.

  • Always add appropriate test code in the tests directory.

  • Consider adding to the examples area.

  • Push the branch to gitlab. It will then be automatically built and tested on gitlab:

  • Once it builds correctly, submit a merge request.


The RASCIL has been designed in line with the following principles:

  • Data are held in Classes.

  • The Data Classes correspond to familiar concepts in radio astronomy packages e.g. visibility, gaintable, image.

  • The data members of the Data Classes are directly accessible by name e.g. .data, .name, .phasecentre.

  • Direct access to the data members is envisaged.

  • There are no methods attached to the data classes apart from variant constructors as needed.

  • Standalone, stateless functions are used for all processing.

Additions and changes should adhere to these principles.

Submitting code

RASCIL is part of the SKA telescope organisation on GitLab.

We welcome merge requests submitted via GitLab. Please note that we use Black to keep the python code style in good shape. The first step in the CI pipeline checks that the code complies with black formatting style, and will fail if that is not the case.

Automated testing in Dask

The CI pipeline automatically executes the test-dask job upon every commit to a branch. This job deploys a new Dask cluster on the Data Processing Cluster in the dp-orca namespace. A scheduled pipeline checks the namespace hourly and removes any deployments that are older than a given time (by default 1 hour).