Skip to main content

BAPCtools

BAPCtools is a tool for creating and developing problems following the CLICS (DOMjudge/Kattis) problem format specified here.

The aim of this tool is to run all necessary compilation, validation, and testing commands while working on an ICPC-style problem. Ideally, one should never have to manually run any compilation or testing command themselves.

We are always interested to know who's using this, so feel free to inform us (e.g. via an issue) if so :) The main user base is sitting in Europe with regular users from the BAPC, GCPC and NWERC. BAPCtools has also been used to prepare problems at the EUC and the ICPC WF.

Installation

There are multiple ways to install BAPCtools:

  • From PyPI: pip(x) install bapctools. This should be a complete installation (including all dependencies and a bt executable) and should work on any Linux-ish system.
  • The bapctools-git AUR package, mirrored here.
  • Run from a Docker image.
  • The development version from git via pip install .. For more information regarding the development version see the installation instructions in contributing.md.

(If you know how to make a Debian package, feel free to help out.)

Windows

Note that BAPCtools makes use of symlinks for building programs. By default, users are not allowed to create symlinks on Windows. This can be fixed by enabling Developer Mode on Windows (only since Windows 10 version 1703, or newer).
In case you're still having problems with symlinks in combination with Git after enabling this setting, please try the suggestions at https://stackoverflow.com/a/59761201. Specifically, git config -g core.symlinks true should do the trick, after which you can restore broken symlinks using git checkout -- path/to/symlink.

Native Windows

If you cannot or do not want to use WSL, you'll need the following in your %PATH%:

  • python for Python 3
  • g++ to compile C++
  • javac and java to compile and run Java.
  • pyctd for checktestdata, see PyCTD

Docker

A docker image containing this git repo and dependencies, together with commonly used languages, is provided at ragnargrootkoerkamp/bapctools. This version may be somewhat outdated, but we intend to update it whenever dependencies change. Ping us if you'd like it to be updated. Alternatively, inside the Docker container, you can run git -C /opt/BAPCtools pull to update to the latest version of BAPCtools, and use pacman -Sy <package> to install potential missing dependencies.

This image can be used for e.g.:

  • running CI on your repo. Also see bt gitlabci which generates a .gitlab-ci.yaml file. Make sure to clear the entrypoint, e.g. entrypoint: [""].
  • running bt on your local problems. Use this command to mount your local directory into the docker image and run a command on it:
    docker run -v $PWD:/data --rm -it ragnargrootkoerkamp/bapctools <bt subcommands>
    

Common Usage

BAPCtools can be run either from a problem directory or a contest directory. This is automatically detected by searching for the problem.yaml file.

The most common commands and options to use on an existing repository are:

A guide on how to set a problem with BAPCtools and what commands to use can be found at docs/workflow.md. The list of all available commands and options is at docs/commands. Additionally, information regarding the implementation is at docs/advanced/implementation_notes.md.

Run

  • bt run [-v] [submissions [submissions ...]] [test_cases [test_cases ...]]

Without arguments, the run command runs all submissions against all test cases. Specify one or more submissions and one or more test cases to only run the given submissions against the given test cases.

Before running the given submissions, this command first makes sure that all generated test cases are up to date (in case generators/generators.yaml was found). To disable automatically regenerating test cases, pass -G (--no-generate), or add no_generate: true to a .bapctools.yaml file in the problem or contest directory.

run

By default, bt run only prints one summary line per submission, and one additional line for each test case with an unexpected result. Use -v to print one line per test case instead.

run -v

Test

  • bt test <submission> [--samples | [test_cases [test_cases ...]]]

Use the test command to run a single submission on some test cases. The submission stdout and stderr are printed to the terminal instead of being verified as an answer file. Use --samples to run on the samples, or pass a list of test cases or directories containing test cases. Use --interactive/-i to run in interactive mode, where console input is forwarded to the submission. In interactive mode the output is not validated. This rebuilds and reruns the program until either control-C or control-D is pressed. It's also possible to supply the test case on the command line directly using e.g. < /path/to/file.in or <<< "10 20".

test

Generate

  • bt generate [-v] [--jobs JOBS]

Use the generate command to generate the test cases specified in generators/generators.yaml. See docs/generators.md for the specification of generators.yaml and see docs/commands.md#generate for the full list of arguents. Use -j 0 to disable running multiple jobs in parallel (the default is half of the available cpu cores).

generate

Validate

  • bt validate [-v] [--input | --answer] [--remove | --move-to DIR] [test_cases [test_cases ...]]

Validate all the .in and .ans for all (given) test cases. It runs all validators from input_validators, answer_validators, and output_validators.

Validators can be one of

  • a single-file program.
  • a multi-file program with all files in a common directory.
  • a .ctd CheckTestData file (this needs the pyctd executable in your $PATH, see PyCTD).
  • a .viva file.

You can use --remove to delete all failing test cases or --move <dir> to move them to a separate directory.

validator

Pdf

  • bt pdf [-v] [--cp]

Use this command to compile the problem.en.pdf from the statement/problem.en.tex LaTeX statement. The generated problem.en.pdf is linked to the problem directory itself, if you want a persistent version of the pdf use --cp.

This can also be used to create the contest pdf by running it from the contest directory.

Updating the Docker Image

This can only be done by maintainers:

$ sudo systemctl start docker
$ docker pull archlinux:latest
$ docker login
$ docker build . -t ragnargrootkoerkamp/bapctools
$ docker push ragnargrootkoerkamp/bapctools
$ ssh <server> sudo docker pull ragnargrootkoerkamp/bapctools

The last step is needed when your CI server is not automatically pulling the latest version.

Metadata

Release files for bapctools 2026.10.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for bapctools 2026.10.0
File Size Uploaded
bapctools-2026.10.0.tar.gz 4.1 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for bapctools 2026.10.0
File Interpreter ABI Platform
bapctools-2026.10.0-py3-none-any.whl Python 3 none any Details

Total release size: 5.9 MB

Release files / bapctools-2026.10.0.tar.gz

Download URL bapctools-2026.10.0.tar.gz
Size 4.1 MB
Tags Source
SHA-256 checksum
How to use checksums
7d2adcf8a6deacf410f8b9277d059126fa3206126c90c75a178e815478f4273e
BLAKE2b-256 checksum
How to use checksums
3f414db7d930f5c8ed5b728b794594ea9a984ad5dad505b41df454fc49bf0ed0
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 14, 2026.

Transparency log

Release files / bapctools-2026.10.0-py3-none-any.whl

Download URL bapctools-2026.10.0-py3-none-any.whl
Size 1.8 MB
Tags Python 3
SHA-256 checksum
How to use checksums
46b49c8546d658832b48a7412fd0e5ae42972983e31e85d96104b361bf19fc72
BLAKE2b-256 checksum
How to use checksums
9fcdc847e59ad104d1997bb21f5175075612d6e1ad79736cdf7425d7aac9fb11
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 14, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

2026.10.0 This release

2 release files

0.2

2 release files

0.1

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page