Packages

Nesta’s collection of tools for meaty tasks. Any processes that go into production come here first, but there are other good reasons for code to end up here.

Code auditing

Packages are only accepted if they satisfy our internal auditing procedure:

  • Common sense requirements:
    • Either:
      • The code produces at least one data or model output; or
      • The code provides a service which abstracts away significant complexity.
    • There is one unit test for each function or method, which lasts no longer than about 1 minute.
    • Each data or model output is produced from a single function or method, as described in the __main__ of a specified file.
    • Can the nearest programmer (or equivalent) checkout and execute your tests from scratch?
    • Will the code be used to perform non-project specific tasks?
    • Does the process perform a logical task or fulfil a logical purpose?
  • If the code requires productionising, it satisfies one of the following conditions:
    1. There is a non-trivial pipeline, which would benefit from formal productionising.
    2. A procedure is foreseen to be reperformed for new contexts with atomic differences in run conditions.
    3. The output is a service which requires a pipeline.
    4. The process is a regular / longitudinal data collection.
  • Basic PEP8 and style requirements:
    • Docstrings for every exposable class, method and function.
    • Usage in a README.rst or in Docstring at the top of the file.
    • CamelCase class names.
    • Underscore separation of all other variable, function and module names.
    • No glaring programming no-nos.
    • Never use print: opt for logging instead.
  • Bureaucratic requirements:
    • A requirements file*.
    • The README file specifies the operating system and python version.