FreeCampus Python

Milestone Challenge: Publish a Tiny Community Library Tool

Deliver a tested, installable command-line tool with documented behavior and reproducible checks.
Open in Colab
  • Goal: Deliver a tested, installable command-line tool with documented behavior and reproducible checks.
  • Estimated time: 2–4 hours of active work.
  • Before starting: Complete the milestone units and their unit challenges.
  • Keep: Your source, observed outputs, checks, and a debugging note.

This community challenge is ungraded. Use the checks to review your own work; there is no submission service or automatic grade. Completion is self-reported in this browser on this device.

1. Publish a tiny community library tool

Model books by unique ID, title, and availability. Provide list, borrow BOOK_ID, and return BOOK_ID commands. Persist JSON at a configurable path. Unknown IDs, borrowing an unavailable book, returning an available book, and malformed storage must fail with a useful message and nonzero exit code. Failed operations must not overwrite storage. Separate model rules, argument parsing, and file access.

Predict an ordinary result before coding. Start with the smallest part you can run and inspect. Use Colab for notebooks and the local workspace introduced in the units for packaging or command-line tasks.

2. Set up the experiment

from dataclasses import dataclass

@dataclass
class Book:
    book_id: str
    title: str
    available: bool = True

# Add catalog rules, storage, and CLI modules.

The starter is deliberately incomplete. Implement the contract; do not change the expected results to match an incorrect implementation.

3. Check the observable results

  1. Borrow, reload, and confirm unavailability; return, reload, and confirm availability.
  2. For every rejected operation, assert an error status and unchanged stored bytes.
  3. Use pytest temporary paths. Test model rules and at least one complete CLI invocation.
  4. Run formatting, linting, type checking, and tests with documented commands.
  5. Install in a clean environment and follow the README, including one executable documentation example.

Record actual outputs beside predictions. Reduce a failure to a small example, change one cause at a time, and repeat the failed check after repairing it.

4. Change one condition

Add an available-titles report without exposing storage internals. Begin with a failing test, make the smallest change, then explain the public interface before and after refactoring.

5. Review a hint after attempting the task

Hint: connect the relevant tools

Model state transitions first. Convert domain errors to CLI messages at the outer boundary. Validate before writing and inject storage paths in tests.

6. Explain and self-review

Deliver the package, tests, CI configuration, sample catalog, README, and a design note. Keep a failing test, repair, and passing result. Ask a peer to reproduce the instructions; this remains ungraded self-review.

Review path: compare your result with the contract

Check the ordinary result first, then the boundary cases and changed condition. Explain which rule justifies each result. An implementation that differs from the hint can still satisfy the contract; explain why yours does.

7. Save your work and record completion

Save the notebook or project somewhere you control. Include one decision, one failed check, its repair, and a result you can reproduce. Record completion after reviewing the checks; you can undo it later.

Not yet recorded.

Return to the milestone overview.

Back to top