Command line, Git, Python, and environments

What you will be able to do

1. Create reproducible work from a clean directory.
2. Implement and test small Python functions.
3. Pin dependencies and explain provenance and license checks.

Prerequisites: dictionaries, loops, functions, exceptions and installed Python or paper tracing. Reuse earlier Builder artifacts only when the task requires them.

This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.

Part 1 Technical instruction

A reproducible build is an evidence chain. The repository records intent and change; the environment declaration records runtime assumptions; tests record expected behavior; and the README lets a second person reproduce the result. A virtual environment isolates project packages but does not make them trustworthy. A lock or constraints file reduces version drift but must be reviewed for licenses, vulnerabilities, and origin. Git history should be comprehensible: small commits, reviewable diffs, and branches that express a unit of work. Treat generated output, secrets, caches, and local configuration as excluded by default.

Mechanism and implementation

A function contract specifies accepted inputs and returned values. Trim only fields whose meaning is stable; an unknown identifier must not be fabricated. Record interpreter, working directory and run command so a path error is distinguishable from a logic error.

Constructed offline example

Save as topic_example.py and run python topic_example.py with an installed Python 3.11+ interpreter. This standard-library construction uses synthetic values; its checks are not provider measurements.

def normalize(row):
    identifier = row.get("id", "").strip()
    if not identifier:
        raise ValueError("missing_id")
    return {"id": identifier, "name": row.get("name", "").strip()}
assert normalize({"id": " A ", "name": " Lee "}) == {"id": "A", "name": "Lee"}
try:
    normalize({"name": "Lee"})
except ValueError as error:
    assert str(error) == "missing_id"
else:
    raise AssertionError("missing ID accepted")
print("normalization checks passed")

Engineering decisions

• Choose what belongs in source control versus generated evidence.
• Decide which dependencies require exact pins and which may use bounded ranges.
• Define the clean-environment reproduction check before coding.

Worked example

A learner receives two inconsistent CSV files. They create a package with normalize_record(), a CLI, tests for missing identifiers and duplicate rows, a README with exact setup commands, and a dependency record. A peer clones the repository into an empty directory and runs the test command. A successful run is evidence; ‘it worked on my machine’ is not.

Diagnose the failure

The valid row returns the exact object; absent ID raises the named error. If the clean copy fails, compare interpreter and working directory before editing logic. Passing code does not establish dependency provenance.

Part 2 Guided practice

Predict both outcomes, then run. Add duplicate-ID handling without changing source inputs. Independently copy the script into an empty directory and repeat your documented command.

Answer criteria and feedback: The valid row returns the exact object; absent ID raises the named error. If the clean copy fails, compare interpreter and working directory before editing logic. Passing code does not establish dependency provenance.

Continue with the downloadable pack below. If the pack or interpreter is unavailable, trace this self-contained example by hand in an input/expected-status/controlling-rule table and label execution unverified. Do not invent passing output. No account, credential, paid call, purchase or actual deployment is required.

Part 3 Remediation

If setup fails, compare interpreter version, working directory, environment variables, and dependency constraints in that order. Rebuild from a clean directory; do not repair the evidence by editing the reproduction log. After repair, reassess with the alternate scenario in scenario_alt.json. A critical authorization, data-handling, evidence-integrity, or prohibited-action failure cannot be averaged into successful practice; it requires targeted remediation.

Part 4 Sources and currency

• https://docs.python.org/3/
• https://git-scm.com/docs
• https://csrc.nist.gov/pubs/sp/800/218/final

Use the workflow decision reference for model/deployment/harness distinctions and controlled comparisons. Source currency must be checked before each cohort. Provider/product behavior is illustrative where mocked; resolve current interfaces only from official documentation in an authorized environment.