Forem: Import Sys

GIT Essentials

Import Sys — Tue, 10 Mar 2026 16:05:35 +0000

You've been crunching day and night making sprite animation and finally you got it. Smooth and pleasant. With sight of relief you run your build... to find out that the character movement is broken!
You checked the movement code and... it is gone!

Before you go inventing a time machine stay awhile and listen. I will tell you how to do it.

Table of content

Installing git
Init repository
Repository trees
Commits
Commits history
Remotes

Luckily for us development is not always like running Diablo on hardcore without saves. You can and should save your progress during development, especially when you are working in team with other developers.
This is the point where version control system (VCS) becomes handy. Today we are going to talk about git.
Git is a distributed version control system that track file changes over time, allowing you to become time and space traveler.

Installing git

Installing git is very straight forward. Just visit the official web site downloads section https://git-scm.com/install/linux and follow the instructions for your operating system.

Once git installed let's check its version to verify installation

git --version

Ok, everything seems fine.

Init repository

Let's start new project

mkdir newgame
cd newgame

nvim main.py

if __name__ == "__main__":
    print("This will be the next Diablo")

For git, to be able to track changes in your project you have to init repository first.
It can be done running init command

git init

This will create an empty repository inside your project folder. If you will list folder content you will find that .git folder was created

ls -la

So what, you will ask?

Repository trees

Yes, currently git did not track anything.
But let's run status command.

git status

As you can see the main.py file is listed in the "Untracked files" section. At least we track that we do not track anything so far :)

But what does it mean?
Now is the most crucial part to understand what git is and how it actually work.

Git is a file system with three states trees:

Working tree
Index
HEAD

and in any moment in time git tracks your project state in all three trees.

Most command you will run will move your changes between this three states.

Let's start unrolling all of this from the "Working tree".
As it names suggests working tree is where work happens. You can edit, remove, move files and folders and git mostly does not care at all.

But when you are good with work you have done you can stage the changes into the "Index" tree using add command

git add main.py

and now if you will check the status

git status

you will see that main.py is moved from the "Untracked files" to the "Changes to be commited".

Let's add some code to the main.py file

from dataclasses import dataclass

@dataclass
class NPC():
    name: str
    greetings: str

if __name__ == "__main__":
    decard = NPC(name="Deckard Cain", greetings="Stay awhile and listen")

    print("You see an old man")
    print(f"{decard.name}: {decard.greetings}")

Let's see what git thinks about this update

git status

Now you see another section: "Changes not staged to commit".
It means that now you have both staged version in the Index tree as well as new changes in Working tree.

You can always check what has been changed by running diff command

git diff

diff --git a/main.py b/main.py
index 5f7d3db..d9211a3 100644
--- a/main.py
+++ b/main.py
@@ -1,3 +1,13 @@
+from dataclasses import dataclass
+
+@dataclass
+class NPC():
+    name: str
+    greetings: str
+
 if __name__ == "__main__":
-    print("This will be the next Diablo")
+    decard = NPC(name="Deckard Cain", greetings="Stay awhile and listen")
+
+    print("You see an old man")
+    print(f"{decard.name}: {decard.greetings}")

As you can see git is watching you.

If you are good with the changes you can stage it once again

git add main.py

and checking the status you can see that there are no unstaged changes and also the diff is empty, meaning that all the changes are now in the Index tree.

git status

Commits

So far so good. But I've promised you a time machine.
This is the point where HEAD tree enters the scene.

You sure that you are done with greeting logic and want to make a save that you can load later if things will go wrong.
You can move your staged changed to the HEAD tree using commit command

git commit

If you run commit for the first time git will ask you to identify yourself, since every change should have it author

Git will ask you to write the commit message. Usually in the commit message you describe features or fixes you have made so later you can easily find your save point.

feat: Deckard Cain said hello!

Save the commit message, and there you have it, your first commit!
Let's take a quick look at the status

git status

it says nothing to commit, working tree clean which means that now we starting with clean Working and Index trees.

Let's go a bit crazy and delete the whole file!

rm -f main.py

ls -l

The code is gone... Diff renders all red...

diff --git a/main.py b/main.py
deleted file mode 100644
index d9211a3..0000000
--- a/main.py
+++ /dev/null
@@ -1,13 +0,0 @@
-from dataclasses import dataclass
-
-@dataclass
-class NPC():
-    name: str
-    greetings: str
-
-if __name__ == "__main__":
-    decard = NPC(name="Decard Cain", greetings="Stay awhile, and listen")
-
-    print("You see an old man")
-    print(f"{decard.name}: {decard.greetings}")

But now we have the time machine!

git reset --hard HEAD

ls -l

Deckard is back!

This particular command reset all trees to their states on the time of commit! But, we will get back to it later.

Commits history

Let's quickly make another commit

#... 
akira = NPC("Akira", "Wanna some heal, adventurer?")
#...

Add changes to the commit

git add main.py

And commit them

git commit -m "feat: add Akira"

Now you have a new save point. But it doesn't mean that your previous commit is lost, you still can reset everything to the gold era of Deckard Cain!

You can look at yours commit history using log command

git log

commit 035e7ecf82bc3966332320c405b34645b5e7b591 (HEAD -> master)
Author: import sys <import.sys.dev@gmail.com>
Date:   Wed Mar 4 21:26:03 2026 +0200

    feat: add Akira

commit 6d5d2d1d8c1d7c67b08f85067724c515b3534ef0
Author: import sys <import.sys.dev@gmail.com>
Date:   Wed Mar 4 20:51:02 2026 +0200

    feat: Deckard Cain said hello!

You see both commits, and every commit has it unique ID.
The HEAD tree is now pointing to the latest commit.

Let's try to reset Akira changes.

Usually you do not need the whole commit information, but only the ID and the commit message, so you can run log with --oneline prefix

git log --oneline

035e7ec (HEAD -> master) feat: add Akira
6d5d2d1 feat: Deckard Cain said hello!

When executing reset command you can specify target commit id

git reset --soft 6d5d2d1

Soft reset means that we reset only HEAD tree, leaving changes staged at Index tree, so you can re-commit them if you want to. But this is the story for another time

Remotes

For now everything is happening on your local machine, and if you will accidentally delete .git folder you will lost all your commits and history. This is no good.

To address this issue remotes exists.

Remotes are basically servers where you can publish and store your commits. This can be literally any machine running git and accessible by the network. Or it can be platform like Github, GitLab, Bitbucket and so on.
We will talk about Github specifically, but the overall flow is identical to the every other platform.
Also I will not cover github account registration and setup, because I will never finish this tutorial otherwise :)

First of all let's check if we have any remotes configured for our repository

git remote -v

As expected there are none of them, so let's go to the github.com and create remote repository.

Now, as you have repository URL you can add remote to your local repository

git remote add origin git@github.com:import-sys/fantastic-fishstick.git

Origin is just a default name for the default remote.
Now if you check remotes

git remote -v

you will find that you have origin remote with two endpoints, for fetching and pushing commits.

origin  git@github.com:import-sys/fantastic-fishstick.git (fetch)
origin  git@github.com:import-sys/fantastic-fishstick.git (push)

Ok, now the fun part.

git push origin main

You just pushed all your commits to the remote, so you can access your work history even if you will burn your computer (don't do it). As a bonus you can share code with other developers to collaborate on the project. Hello FOSS.

Let's actually wipe everything, to prove the point

cd ..
rm -rf newgame

Your code is gone, you local git history is gone, but you can restore everything with a single command!

git clone git@github.com:import-sys/fantastic-fishstick.git newgame

ls -l newgame

You've just cloned remote repository into local repository.
Let's quickly check it

cd newgame && ls -l 

git log --oneline

All the files and commits are there as if I have never delete them!

If someone make another commits to the remote repository you can pull remote changes using following command

git pull origin main

Now you are up to date with remote server, and in the log you will see the new commit

git log --oneline

That's it, your remote is all set up.

I know, it was tough. But understanding how you can manipulate git tree states is a key to more advanced git topics. Next time I will touch git topic we will discuss why trees are actually trees, cover branches, merging, rebasing and other cool stuff.

Managing python virtual environments

Import Sys — Wed, 04 Mar 2026 07:45:52 +0000

If you are working on multiple projects you might have run into a problem — different projects requiring different versions of the same package.

Today we are going to solve this with python virtual environments. You'll learn what they are, how to create and use them, and how they actually work under the hood.

Table of content

Why to use virtual env
What is the virtual env
Create virtual env
Activating virtual env
Installing packages
Deactivating virtual env
Under the hood
Removing virtual env

Why to use virtual env

Imagine you are working on the two projects that both use the requests package as a project dependency.
Now you will have a dilemma.
If you installed requests package system-wide you will have to use same package version for the both projects.
But, let's say your first project is in a production state and you have to stick with the specific package version. On the other hand while building your second project you want to use new features from the latest package release.

Luckily you can use virtual environments!

What is the virtual env

Virtual environment is the isolated python environment which allows you to manage dependencies separately.

Create virtual env

Starting from the version 3.3 python provides built in mechanism to create virtual environments - venv module.
Let's create virtual environment.

python -m venv ./virtualenv

To create virtual environment you have to run venv module specifying the path where virtual environment will be created.

Activating virtual env

To be able to use specific virtual environment you have to activate it first.

source virtualenv/bin/activate

If you are using Windows you should use activation script for windows also available in the virtual env folder.

virtualenv\Scripts\activate

Now you can see the terminal prompt has changed which means that you are working in the virtual environment.

Installing packages

Package installation is exactly the same as without using virtual env. But now the packages are isolated to the current virtual environment.
Also now it much safer to use pip directly since it bound to the specific python environment

pip install requests

Now it have much more sense to provide requirements.txt file with the project since you can isolate packages for every project. And the installation process does not differs at all.

Let's take the requirements file from the PIP tutorial and install all the packages listed.

cat requirements.txt

pip install -r requirements.txt

Now we can check the installed packages in the virtual environment

pip list

Cool, we have our packages installed. But how we make sure that they are isolated?

Deactivating virtual env

Let's leave virtual environment by running deactivate command

deactivate

Note that all the packages you've installed in the virtual environment are still there you just leave environment itself.

And now if we check the packages list

python -m pip list

python -m pip show numpy
python -m pip show openpyxl

You see that there are no packages that were installed inside the virtual environment.
So you can tell isolation is working.

Under the hood

Okay, but what is the magic actually?
Let's activate our virtual environment once again and see how it works.

source virtualenv/bin/activate

When we run python or pip, what do we actually run? Let's check

which python 
which pip

As you can see python interpreter as well as pip are located inside our virtual environment.

Every time you create virtual environment you get dedicated python interpreter and package manager.

Ok, but how does system knows that it should run this exact python interpreter?

Let's check the PATH variable

echo $PATH

As you can tell our virtual environment now is the first location where system will look for the executable. So activating virtual environment will automatically update your PATH variable adding virtual env location on top.

Ok, cool. But what about packages? Let's see

ls -l virtualenv/lib/python3.14/site-packages

Here they are! All installed packages are stored inside virtual environment too.

So that's how you can have different dependencies of different versions for your every project. Just create own virtual environment for every project!

Removing virtual env

Obviously you can remove virtual environment. You can simply remove the virtual environment folder, and that's it. But do not forget to deactivate it first

deactivate
rm -rf virtualenv

And that's virtual environments! Now you know how to keep your project dependencies clean and isolated.

Installing and managing python packages via PIP

Import Sys — Tue, 03 Mar 2026 09:47:52 +0000

If you've been following Python tutorials, you've probably seen "just run pip install something" - but what IS pip? Where do packages come from? And why does this sometimes break?

Today we're demystifying Python package management. You'll learn what pip is, how to use it, and how to avoid common mistakes that break your projects.

Table of content

Introduction to the packages
Introduction to the PIP
Installing packages
Removing the package
Upgrading packages
requirements.txt file
Versioning

Introduction to the packages

Imagine you have to fetch some URL on the internet. Sure, you can learn all the levels of the OSI model, write your own encapsulation/decapsulation implementation, learn HTTP specification and implement it.

Or you can use the python requests library.

Sounds good, but where will you get this library and packages?

Simple. Python ecosystem has Python Package Index (PyPi) which is the official python packages repository.

Open your browser and navigate to pypi.org.

Here you can search for the package you need. Just type requests in the search bar and navigate to the package details page.

Here you can find all the information you need. Usage examples, authors, links to the documentation and the source code is available as well as installation instructions.

As you can see we were instructed to use the pip command to install the package. But what is PIP?

Introduction to the PIP

PIP is the standard package installer for python.
Usually you don’t have to install PIP manually, but it is always a good idea to check if it installed and it version

python -m pip --version

If pip is not installed you can simply install it by running ensure pip module

python -m ensurepip --default-pip

Ok, PIP is working, so we can get back to the package installation.

Installing packages

To install the package you will use the install command. Simple, isn’t it?

python -m pip install requests

That’s it. You’ve installed the package. Now you can use list command to check the installed packages

python -m pip list

As you can see, the request package of the specific version is installed.
But there are some other packages that we have not installed. Where did they come from?

Let’s run command

python -m pip show requests

This command will show details of the installed package.
Take a closer look at the Requires section.
Yes, the package can depend on other packages, and PIP will resolve these dependencies automatically!

If you look at the details of the certifi package, for example, you will see that this package is required by the requests package.

python -m pip show certifi

Removing the package

To remove the package you can use uninstall command

python -m pip uninstall requests

Note, that uninstalling a package will not remove its dependencies since other packages can be dependent on it.

Let’s reinstall requests package once again

python -m pip install requests

And now let’s try to remove one of the requests package dependency

python -m pip uninstall certifi

Pip will allow you to remove it, but your “requests” package will be broken. You can use command check to check if you have some broken dependencies.

python -m pip check

As you can see PIP is notifying you that you are missing requests package dependency. You can fix it by reinstalling the requests package, or by installing a certifi package itself.

python -m pip install certifi

python -m pip check

But, I would recommend reinstalling the requests package itself since it may be dependent on the specific version of the certifi package and installing another version may leave your setup broken.

Upgrading packages

Let’s actually try it by installing an older version of the certifi package.

python -m pip uninstall certifi 
python -m pip install "certifi==2015.4.28"
python -m pip check

PIP is telling us that we use an outdated version of the certifi package.
But you can update the package specifying --upgrade flag to the install command

python -m pip install --upgrade certifi
python -m pip check

As you can see certifi package is successfully upgraded.

requirements.txt file

We’ve almost done with the packages. But imaging you are working on a project that requires several dependencies.

For example you need a requests package to fetch data, numpy package to analyze data and openpyxl to make XLS reports.

Sure you can install this packages on your machine:

python -m pip install requests numpy openpyxl

But what if you have to share your code with someone else? Yes, you can message another developer and tell that he or she should install specific dependencies of specific versions, but this solution is not very scalable.
Or I would say not scalable at all.

Instead you can prepare requirements.txt file with all of the project dependencies and their versions.

cat requirements.txt

requests==2.32.5
numpy==2.4.2
openpyxl==3.1.5

Now you can share this file as part of the project and install all the required dependencies using following command

python -m pip install -r requirements.txt
python -m pip list

And you can also upgrade all the packages listed in the requirements file adding –upgrade flag to the install command

python -m pip install -r requirements.txt --upgrade

Versioning

During this talk I mentioned package versions several times. But what is the version after all?
Python is mainly using two versioning schemes: semantic versioning and calendar versioning. I am gonna talk about semver here.
So let's check requests package details:

python -m pip show requests

As you can see we've installed requests version 2.32.5.
Each number in the version has its meaning:

2 is the major version. Major version updates when you introduce public API changes and do not grant backward compatibility
32 is the minor version. Minor version updates when you add functionality in backward compatible manner
5 is the patch version. Patch version updates with the bug fixes and patches

Why all this information matters?

Well, when you see new version of the package released you almost always know is it safe to update.

If patch version changed - great, safe to update, just bug fixes.
If minor version changed - usually it is safe to update, but I suggest spending some time reading release notes.
if major version changed - well, better start new project :)

But let's say we want to automatically update patches and minor versions of the library, but do not want to switch to the major version.

Let's get back to the our's requrements.txt file:

cat requirements.txt

Here we can specify exact version requirements we need. Let's update requests library version requirement

requests >=2.32.5,< 3.0.0

So now we say that we want at least version 2.32.5 but not the 3rd major release.

And every time you run

python -m pip install --upgrade -r requirements.txt

you will update requests library to the latest version of the 2nd major release.
Isn't it cool?

It's also worth to mention that you can (and should for production environments) lock the specific version of the package. Like we did for the numpy and openpyxl packages in the requirements.txt file.

I hope that now you have a better understanding of how to use third-party packages in your projects!