Background and motivation | Who is this for? | Installation | Project setup: init_project() and create_qmd() | Starting with init_project() | Adding a Quarto document with create_qmd() | With examples (the default) | Without examples | Custom styling | The purl hook | Pre-populating the YAML header | Summary of what gets created | Working with data | Reading and writing clean data: read_clean_csv() and write_clean_csv() | Splitting and applying: write_by_group() and run_by_group() | Recording what an analysis produced: save_output() and generate_manifest() | Reading output records back: read_output_records() | Auditing a project: check_project() | Execution context: detect_execution_context() and resolve_input_path() | Knowledge Base export: generate_kb_xml() | Citation metadata: generate_citation() | Syntactic trees: arborize() | Quick reference | Citation

The promise of a first CHTC job | The larger idea: make the right choice easy | What submitr does | Before you submit anything | A small example analysis | Step 1: configure your CHTC connection | Setting up SSH connection reuse | Step 2: generate the submit file | Step 3: generate the executable script | Step 4: preview and upload files | Step 5: submit the job | Step 6: check progress | Step 7: download results | The submission state | From one test job to many HTC jobs | Where containr fits | A practical first-submission checklist | What submitr does not do | A good first goal

Why two modes? | The analysis | The job manifest and the submission state | Single mode: one dataset, one job | Building the container | Generating the submit file and executable | Submitting and downloading | Multiple mode: one analysis, three species | Splitting the data | Side-by-side comparison | What lives in the container | The .sub file | The .sh file | The R script | Files uploaded to the submit node | Files downloaded after the job | How htc_download() resolves files | How the two files relate | A note on the results naming change | When to use which mode

Before you start | Step 1: Generate a Dockerfile | Step 2: Build the image | Step 3: Inspect local images | Step 4: Push the image to the registry | Putting it together | Troubleshooting

You already care about reproducibility | What renv does -- and does not do | What a container adds | The Dockerfile as a reproducibility artifact | Where containr fits | What comes next

The problem | How arborize() solves it | A note on first use | Two rendering backends | tree_notation = "simple" -- bracket notation | tree_notation = "structured" -- lingotree notation | Getting the crop right: papersize and margin | Choosing a papersize | Choosing a margin | The general workflow | Examples | A simple NP | A clausal tree | Aspectual classes | Print-quality output | Tight crop with a narrow margin | Structured notation with lingotree | Suppressing the provenance file | Working with provenance files | Embedding trees in documents | Argument reference | References

The problem | The three contexts | The solution | A worked example | Connecting to create_qmd() and qmd_to_r() | Summary

The problem with maintaining a CV | The curriculr model | How curriculr compares to other approaches | Word or Pages documents | LaTeX CVs | vitae | datadrivencv | The Excel advantage | A note on reproducibility | Getting started