For my lab, I worked on my repo ContextWeaver and I used Python’s packaging tools and published my project on TestPyPI using build and twine, since Python packages are all managed through PyPI and TestPyPI. The process was pretty detailed. I had to reorganize my code into a proper src/contextweaver structure, create a pyproject.toml with all the metadata, bump versions every time I re-uploaded, build the package using python -m build, and then upload it with twine.
I learned a lot about how strict packaging actually is especially versioning (you can’t reuse a version, or TestPyPI will reject it), and how the description shown on PyPI actually comes from your README.md. My “aha” moment was realizing that I had to update the version and pull the changes locally before rebuilding, otherwise I’d keep uploading the wrong version. I didn’t need to change my code logic, but I did have to clean up my file structure and add installation sections to my README so it made sense for real users.
For user testing, I asked my friend to follow only the README, and they immediately got confused about installation, Python version, and how to run the CLI. I took notes and updated the README to include installation (pip install), Python 3.10+ requirement, CLI examples, and troubleshooting. Now users can install my project with a simple pip install contextweaver, and they can run it using commands like contextweaver . -o snapshot.txt. Overall, the release process forced me to think about how a real user would experience my project, and updating the documentation made a huge difference.
Top comments (0)