Packaging and Release Project: Python Applications

Outcome

Design a package boundary and a release checklist that proves the installed artifact works.

Why it matters

At this level, code is judged by how safely it changes under load, failure, and team ownership. The technique in this lesson makes an important boundary visible enough to test and review.

Concept

A package is an interface. Keep importable logic separate from the CLI adapter, declare the build in pyproject.toml, and test the built wheel in a clean environment rather than trusting the source checkout.

Read the code

def exit_code(processed: int, rejected: int) -> int:
    if processed == 0:
        return 2
    if rejected > 0:
        return 1
    return 0

for case in [(4, 0), (4, 1), (0, 0)]:
    print(case, exit_code(*case))

Read from the public behavior inward: identify the input boundary, the decision, and the observable result before studying syntax.

Release checklist: follow the artifact

A source-checkout test and an installed-wheel test answer different questions.

This is a proposed verification journey for the practical challenge, not evidence that a package has already been built or published.

1. Source and build declaration

Importable logic + CLI adapter

Build using pyproject.toml

Source check: Test the function behavior here.

Passing here does not prove that the wheel includes the modules or declares the console entry point.

2. Built wheel

Build output: .whl file

Install this exact artifact

Artifact check: Keep the wheel identity with your test record.

Install the wheel, not an editable link back to the checkout.

3. Clean environment

Fresh virtual environment

Installed package + declared dependencies

Isolation check: Run outside the checkout without source paths injected.

A fresh environment alone is not enough if imports can still fall back to the source tree.

4. Installed CLI check

Installed console entry point

Observe output and process exit status

Contract check: Exercise the documented success and failure cases.

The Python function returns an integer; the CLI adapter must turn its result into a process exit status.

Record what each check proves and any failure before deciding to release. Building, installing and testing locally do not publish a package. This diagram does not supply the prediction answers or perform the release checklist.

Predict the output

Predict the exact output before running the example.

Check your prediction

(4, 0) 0
(4, 1) 1
(0, 0) 2

The exit codes are 0, 1, and 2. The CLI adapter can translate domain outcomes into a stable automation contract.

Modify the code

Change one valid input into the nearest invalid or overloaded case. Write down which layer should reject it and what the caller should observe.

Review the change

Keep the failure at the narrowest boundary that owns the rule. Preserve a stable return value or exception contract so callers do not need to inspect implementation details.

Debug the bug

Testing python module.py from the repository does not prove the wheel contains the module or installs its console entry point. Test the artifact in an empty environment.

Try it yourself

Complete the focused implementation and run its deterministic checks.

Loading this exercise…

Practical challenge (optional)

Create a package layout, build a wheel, install it into a new virtual environment, and record a five-step release checklist with rollback.

Sign in to track your progress on this exercise.

AI collaboration

Checkpoint

Why does running a module from the source checkout not validate the built wheel?
What belongs in pyproject.toml for a reproducible package boundary?
What automation contract do exit codes 0, 1, and 2 express in this exercise?

Answers

The source tree can make imports succeed even if the wheel omitted a module or console entry point.
The build backend, project metadata, dependencies, supported Python range, package discovery, and declared entry points used by the project.
Success, partial rejection, and no work respectively; callers can branch without parsing human-readable output.

Sign in to track your progress on this exercise.

Summary and next step

You made the boundary explicit, predicted its behavior, tested a deterministic implementation, and examined its failure mode. Continue to the next lesson to combine this technique with a wider application or production constraint.