Why I started this

Turning a script into a CLI

The folder structure that made it clean

How the package became installable

Publishing to PyPI

What I added to make it contributor-friendly

Clean Git history A few days ago, I had a simple idea: What if I could type internetspeed in the terminal, press Enter, and instantly see my internet speed and public IP? That tiny thought turned into a real project, a GitHub repository, an installable Python CLI, and eventually a PyPI package that anyone can install with: Git Repo: https://github.com/cranky420/internetspeedtest.git This post is about how I built it, what broke along the way, why open source matters, and what I learned from turning a local Python script into a real distributable tool. I wanted something that felt as natural as Linux commands like: I started with a local Python script that did three things: The first version wasn’t elegant. It was just about proving the idea. I used requests to fetch the public IP from a public API, then used a test function to measure network throughput. That gave me the first “it works” moment. And that matters a lot. In open source, people often jump too quickly to packaging, publishing, branding, and documentation. But the real first step is always the same: Make one small thing work. !Image description(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qlk6vhoms7cb6xlh2h2d.png) That sounds small, but it changes everything. A real CLI feels like software.

A script feels like a file. My project started to look more like a proper CLI application instead of a personal script. Here is the general shape of the command: And then the command itself: That’s when it started feeling real. I began with a messy folder, like many first projects do. But once I wanted to publish it, I needed a cleaner structure. My repo eventually looked like this: internetspeedtest/├── cli.py├── speed.py├── setup.py├── README.md├── requirements.txt├── LICENSE├── CONTRIBUTING.md├── .gitignore└── venv/ The real transformation happened when I made the project installable as a command-line tool. That meant adding setup.py and defining a console entry point. Here is the essential idea: from setuptools import setup This tells Python packaging: After installing the package in editable mode: That was a huge milestone. It meant the project was no longer just code in a folder. It was software with an interface. At first, I got 403 errors. Later, I realized it was just a credential flow issue. That kind of debugging is part of open source too. A project becomes real when you learn how to ship it, not just how to write it. This was the moment the project became global. Once the package was built properly, I could upload it to PyPI and make it available to anyone. That means anyone can now do: That’s a massive shift. A local repo became a public tool. That is one of the most satisfying parts of software development: turning something personal into something shareable. I did not want this to be a closed personal tool. I wanted it to be open source because open source turns software into a conversation. Once a repo is public, other people can: If you want other people to help, you need to make the project welcoming. That means adding things like: This explains what the project does, how to install it, and how to use it. This tells people how to participate. Small, clear commits are easier to review and understand. Open source does not start with “welcome contributors.”

It starts with making the project readable. What internetspeed actually solves At first glance, this may look like a tiny utility. But it solves a real workflow problem. Sometimes you want to check: What I actually learned was this: Open source is not just code. It is packaging, documentation, publishing, maintenance, debugging, and community design. That was the biggest lesson. A project becomes open source only when someone else can realistically use it, understand it, and contribute to it. The long-term vision is to make it easy for anyone to check and observe their network speed from the terminal, and maybe even use it as part of a larger monitoring workflow. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse