This is the third post in a series focusing on #100DaysofCode. In the first post, I covered why network engineers should consider investing time and energy into Python. In the second post we got started building a Python development environment focused on ease of use and setup so the bulk of time can be spent coding. Now, let’s finish strong by learning how to isolate and containerize our development environment, how to add packages, and how to commit our code to a remote repository for posterity, accountability, and reference.
Ride, Postman!
By this point, we have a functional Ubuntu box with PyCharm and Postman at a minimum. Wait, we don’t have Postman? Oh, it turns out Postman isn’t in the Ubuntu Software Library. Oh well, time to get comfy with CLI using the terminal.
The good news is, Ubuntu has several package managers, one of which works perfectly for this. We’ll install it in a snap. Or with a snap. Snap.
This isn’t a post about Postman, but understand that Postman will help immensely down the line once we get to API interactions. Instead of troubleshooting your Python code, you can use Postman to send API calls and verify the calls work and what data is returned. Postman is worth its weight in gold for writing Python code that interacts with APIs which starts around Day 32/33.
Python in a Box! (Sort Of)
Now let’s focus on creating a Python virtual environment. The purpose of a virtual environment, or venv for short, is to containerize your coding. This allows you to install packages of specific versions without worrying about the impact it will have with your other code outside the venv. In short, if you can imagine the pain of trying to juggle apps on a computer that require different versions of Java to work correctly, you understand the value of a venv (and containers in general).
So let’s build one!
What we want to do is create a directory (using mkdir) to house our virtual environment. However, on this Ubuntu Desktop, the ability to create virtual environments isn’t an included package (though python 3 itself is included).
No big deal, we just need to install the package.
Notice now the extra prompt added showing the name of the venv in parenthesis. This indicates the venv is active. Note this will now disappear if you leave this directory. From here on, until you type deactivate or reboot, any pthon packages you install will only persist inside the venv. Let’s add a folder to save our Day 1 project code into, and start PyCharm.
When you start a new project, you have to decide where to save the code you create. I would click the folder to the right of Location and browse to the Day1 folder. Every day is a new project, so this will be the workflow for the rest.
Technically you can use PyCharm to make the venv also, but as we will be switching projects often I don’t want to accidentally recreate the venv if I am not paying attention. This workflow ensures the venv will stay persistent through the 100 Days.
Git Gud!
Now let’s set up a GitHub account and get a code repository to commit to. There are TONS of blogs about how to enroll and set up a GitHub repo, so I won’t be exhaustive here but I will make some suggestions.
The .gitignore file tells git what files/directories not to upload to the code repo from your local machine. Examples of files you probably don’t want in a publicly accessible repository might include a file that contains passwords, for instance.
Git doesn’t come standard on Ubuntu Desktop, but it’s easily installed in the same way we did Python venv. After installing, we should set up a special Git repo directory and see if we can clone our repo down to the local machine.
PyCharm Redux
I made a small mistake in doing PyCharm first, but it’s an easy fix.
We just need to make sure our Project directories point at our git repo, not the other directory. That makes adding and committing code much simpler. We can also set it so that any new project we create also uses the venv.
Now that we fixed that, let’s scrap the current unused project and recreate it. Remember that every day we’ll be creating a new DayX folder in the gitrepo directory.
Next we just need to tweak our .gitignore file to add the PyCharm .idea hidden directory. This will keep it from being added to our git upload.
Now that we should only be adding files we want to get uploaded, let’s just do a quick test push.
Almost there!
Last thing to do is check the repo.
Okay, now we can be sure that every time we add a new Day, a new python file, we can commit it to the remote repository. Get coding!
