Adding external libraries to your assignment

If your assignment uses anything beyond the language's standard library — numpy in Python, dompurify in JavaScript, gsl in C, gson in Java — CodeTeach has to install that library before validation can run your solution and before the autograder can grade student submissions. Most of the common libraries auto-install with no configuration. Some need a one-time setup. This article shows you which is which and how to configure the ones that aren't automatic.

The Dependencies panel

When you paste code into the Seed step (Forward, Backward, or Both Provided modes), CodeTeach scans the imports/includes/requires and shows a chip for each library it finds. The chip color tells you the status:

• ✅ Green chip — auto-installed. You don't need to do anything. Examples: numpy, requests, dompurify, axios, gson, org.junit, the <openssl/> family of C headers.
• ✅ (no chip — silent) — language standard library. Always available. Examples: Python's os / json / re, C's <stdio.h> / <stdlib.h>, Java's java.util.*, Ruby's csv.
• ⚠️ Amber chip with Configure button — unknown library. Click Configure to tell CodeTeach how to install it.

A counter at the top of the panel shows how many libraries still need configuration. If it says "0 needs configuration" you're good to generate; if it shows a number, click each amber chip to configure it.

What auto-installs per language

Different languages have different "common library" lists. Here's what's covered without configuration:

For languages where "anything in the public registry auto-installs" (JS/TS, Ruby, Go, C#, Rust), the Dependencies panel won't even show a chip in most cases — you can use any package without configuring anything.

For Python, C/C++, and Java, the auto-installer covers the common ground. If you import something outside the auto-list, you'll see an amber chip and need to configure it.

Configuring an unknown library

Click the Configure button on the amber chip. An inline form opens with fields specific to your language.

Python example: configuring pendulum

You paste a starter that imports pendulum (a niche timezone library not on the auto-installed list). The chip shows ⚠️ amber.

Click Configure. The form asks for:

• Import name — pre-filled with pendulum (the import root we detected)
• pip package — what pip install should be told to install. Usually the same as the import name; for pendulum, type pendulum. If you want a specific version, type pendulum==3.0.0.

Click Save. The chip turns green ✅. You're done — pip install pendulum will run before validation and before the autograder grades student submissions.

C/C++ example: configuring gsl/gsl_math.h (GNU Scientific Library)

You paste a starter that includes <gsl/gsl_math.h>. The chip shows ⚠️ amber.

Click Configure. The form asks for three fields, with sensible defaults:

• Header name — pre-filled with gsl/ (the prefix that covers all <gsl/*.h> includes from one configuration). You can narrow this to a specific header like gsl/gsl_math.h if you want, but the prefix form is usually right.
• apt package — what apt-get install should fetch. Pre-filled with the heuristic libgsl-dev (which is correct for GSL — the heuristic is right ~70% of the time for standard Linux libraries).
• Linker flags (space-separated) — pre-filled with -lgsl. Override this to -lgsl -lgslcblas -lm because GSL needs three linker flags, not just one.

The form has helper links (Search Ubuntu packages, Search pkgs.org) so you can verify the apt package name and required linker flags before clicking save.

Click Save. The chip turns green ✅. The autograder workflow will now apt-get install -y libgsl-dev and pass -lgsl -lgslcblas -lm when compiling.

Java example: configuring com.example.coolib

Pre-filled fields:

• Import root — pre-filled with what we detected
• Maven coordinate — groupId:artifactId:version. If you don't know the exact coordinate, the helper link to Search Maven Central is one click away.

Click Save. The library is added to the generated pom.xml.

Adding a library proactively (before pasting code)

Sometimes you know your assignment will need a specific library and want to configure it in advance, before pasting code. Click Add custom library (advanced) at the bottom of the Dependencies panel — same form as the Configure button but lets you type the import name from scratch.

Useful when you're building an assignment around a niche library and want to confirm CodeTeach can install it before generating the AI artifacts.

What the configuration actually does

The library configuration ends up in two places:

1. Tier 1 sandbox validation — when CodeTeach tests your solution against the autograder tests in our sandbox, it installs the configured libraries so the solution can compile and run.
2. Tier 2 / GitHub Actions workflow — the generated workflow YAML includes install steps so when a student pushes their submission, GitHub's runner installs the same libraries before grading.

The configuration is stored on the assignment session (not on your account), so each new assignment that uses the same library needs to be configured separately. Future versions of CodeTeach will let admins set a per-instructor allowlist so the same pendulum config you set up once never has to be set up again — for now it's per-assignment.

Common gotchas

The apt package name doesn't follow lib<X>-dev. The auto-fill heuristic is right most of the time but Ubuntu has weird outliers — e.g., <uuid/uuid.h> needs uuid-dev, not libuuid-dev. The Configure form's helper link to Search Ubuntu packages by content lets you search "which apt package contains uuid.h" and get the right answer in one query.

You need multiple linker flags, not one. GSL is the canonical example — it needs -lgsl -lgslcblas -lm. The auto-fill gives you -lgsl only. Override the linker flags field when documentation tells you a library needs more than one.

Specific version pinning. Useful for: assignments where library behavior changed between minor versions, autograder regression tests that depend on specific output formatting. Type <package>==<version> for pip / <gem>:<version> for RubyGems / <groupId>:<artifactId>:<version> for Maven.

The library doesn't exist. If you typo'd the package name (e.g., numby instead of numpy), validation will fail with a clear "package not found" error. Open the Dependencies panel, click the chip, fix the package name in the Configure form, re-save.

Standard-library imports show as unknown. Rare, but happens when CodeTeach's stdlib detection is incomplete — e.g., a Python __future__ import or a C <sys/foo.h> POSIX header that's not in our list. If you're sure it's stdlib, click Configure and use the Mark as stdlib option (if available) or just leave it unconfigured — the auto-installer will treat unknowns as harmless if they don't actually need installation.

Where to go next

• For more on the Seed step itself, see Picking a generation mode.
• For diagnosing failures during validation, see Common validation failures and what they mean.
• For the broader autograder workflow that consumes these libraries at student-grading time, see The autograder check.