Python Packaging & pip

Here is a practical Coding Challenge based in a concepts taught inside Python Packaging & pip materials.

Coding Challenge: The Modern Package Architect

Problem Description Imagine you're actually the lead engineer for a blazing-fast data aggregation dashboard. You have just separated out the highly optimized, core data-fetching module called data-streamr and your team wants towards share it with a world so other developers can simply type pip install data-streamr.

Historically your team used an outdated, messy setup.py script. Because this was a living Python script it mostly executed unpredictable code during installation and caused massive headaches. Also, junior developers keep trying to test their deployment directly on the live PyPI servers, risking global errors if they make typo in a code;

your challenge is to architect a modern, production-grade deployment pipeline. You must completely abandon setup.py and write a strict declarative pyproject.toml manifest file. You've got to define build system using a modern build tool (like Flit, Hatch, or Poetry), declare your project metadata, and provide an exact terminal commands required to build the "Wheel" and safely upload it to a practice clone of the PyPI server before production.

Difficulty Level: Advanced

Input & Output Specifications * Input: * Raw Python source code inside a data_streamr directory. * Output: * THE syntactically valid pyproject.toml configuration file replacing the legacy setup script. * A CLI commands to build the package into compressed distribution file (Wheel). * The CLI commands to safely upload distribution files without touching the live global PyPI database.

---

Starter Code Boilerplate

# pyproject.toml

# 1. Define the build system
[build-system]
requires = ["<INSERT_BUILD_TOOL_REQUIREMENT_HERE>"]
build-backend = "<INSERT_BUILD_BACKEND_HERE>"

# 2. Define the project metadata
[project]
name = "data-streamr"
version = "1.0.0"
description = "A blazing-fast data aggregation module."
authors = [
    { name="Your Name", email="[email protected]" }
]
requires-python = ">=3.10"
dependencies = [
    # Add the famous HTTP library dependency here
]

# Terminal Commands to execute

# 1. Command to build the distribution (Wheel and sdist)
$ <INSERT_BUILD_COMMAND_HERE>

# 2. Command to safely upload the built packages using twine to the practice server
$ twine upload --repository <INSERT_REPOSITORY_NAME> dist/*

---

Hints * A Blueprint Manifest: pyproject.toml isn't a Python script; it is just pure configuration (TOML format). It acts as strict shipping manifest that safely declares exactly how your factory machinery should basically build package. * The Factory Machines: You must populate the [build-system] table. modern Python ecosystem is decoupled meaning you can choose tools like flit_core hatchling, or poetry-core as your build-backend to do heavy lifting of packing your code. * Dependencies: Remember that modern web fetching relies heavily upon external libraries; be sure towards list the undisputed king of Python web requests (the requests library) under your dependencies. * Safe Deployment: Never test your code on the live production server! Advanced developers always practice deploying to TestPyPI. TestPyPI is the identical clone of the real server where you can safely upload and verify your package without risking production errors.

---

Test Cases

1. Test Case 1 (Valid Configuration & Build):
2. Action: Run the build command (e.g., python -m build) in same directory as your completed pyproject.toml.

3. Expected Behavior: The build backend successfully reads the strict TOML manifest, compiles a source code without running arbitrary setup scripts and generates a highly compressed .whl (Wheel) file inside the /dist folder.

4. Test Case 2 (Legacy Rejection):

5. Action: An automated CI/CD pipeline attempts to search for setup.py to execute.

6. Expected Behavior: A pipeline fails gracefully, and by exclusively relying on pyproject.toml, you mathematically prevent any arbitrary code execution during a package metadata resolution phase, proving the new architecture is safer.

7. Test Case 3 (Simulated Safe Deployment):

8. Action: Execute the twine upload command provided in your solution.
9. Expected Behavior: Twine packages a Wheel and successfully uploads it to the testpypi repository endpoint; a developer on a different machine can then run pip install -i https://test.pypi.org/simple/ data-streamr to safely verify an installation before pushing the final version to real PyPI for the world to see.