Add slides on the cost of adding dependencies

Read 04_dependencies_ci.qmd around the opening Dependencies section and Dependency resolution, then review group_work/04_module.md for the existing Q3. Add the proposed dependency trade-off material in the specified location, optionally adding the follow-up question, and verify that the rendered module presents the new slides coherently.

Module 04 introduces dependencies and how to manage them with uv, but doesn't discuss the harder question: should you add this dependency at all?

This is especially relevant for scientific/engineering packages where a single poorly chosen dependency can make installation painful for end users (think compiled C extensions that won't build on a colleague's Windows laptop).

The two camps

In practice, teams tend to fall into two extremes:

1. "Not invented here" — rebuild everything from scratch, avoiding external code even when well-tested libraries exist. This leads to buggy reimplementations and wasted effort.
2. "pip install whatever" — especially common with junior developers, grabbing packages without considering licensing, long-term maintenance, or what you're pulling into your dependency tree.

Neither extreme is right. The goal is to make deliberate, informed choices about each dependency.

Suggested slide content

A new slide section in 04_dependencies_ci.qmd, after the current "Dependencies" intro and before "Dependency resolution". Suggested bullets:

• Every dependency is a trust decision — you're shipping someone else's code to your users. In 2016, an npm developer unpublished a tiny 11-line package called "left-pad" and broke thousands of projects worldwide, including React and Babel. Your water model shouldn't stop working because a string-padding library disappeared.

• Transitive dependencies add up fast — adding one package can silently pull in dozens more. Each one is a potential point of failure — version conflicts, broken releases, or abandoned maintenance. Run uv pip tree to see what you're actually shipping.

• Supply chain attacks are real — malicious code has been injected into popular packages (npm's event-stream, Python's ultralytics on PyPI). The more dependencies you have, the larger your attack surface. For packages used in infrastructure or safety-critical modelling, this matters.

• Check the license — not all open-source licenses are equal. GPL dependencies can force your entire package to be GPL. Some licenses restrict commercial use. Always check before adding — your legal team will care even if you don't.

• Consider the maintenance horizon — will this dependency still be maintained in 3 years when your model is in production? Check: How many maintainers? How recent are the releases? Is there a bus factor problem? For scientific packages, also check: does it require compiled extensions that complicate installation?

• When NOT to add a dependency — if you only need one function from a large library, consider copying the logic (with attribution). If the functionality is 10-20 lines of straightforward code, just write it yourself. Your future self debugging an install issue on a server will thank you.

• When TO add a dependency — don't reinvent NumPy or pandas. Well-established, well-maintained packages with large communities (numpy, scipy, matplotlib) are safer bets. The key question: does this dependency solve a genuinely hard problem that would be error-prone to implement yourself?

Placement

Between the current opening slide ("Dependencies are other pieces of software...") and "Dependency resolution" in 04_dependencies_ci.qmd. Could be 1-2 slides titled something like "Should you add this dependency?".

Group work tie-in

Q3 in group_work/04_module.md already asks about conflicting dependencies. Could add a follow-up: "Have you ever regretted adding a dependency? Or avoided one and regretted reimplementing it yourself?"