DEV Community

Cover image for Djangonaut Diaries: Week 1 — Setting up the space (and the machine)
rodbv
rodbv

Posted on

Djangonaut Diaries: Week 1 — Setting up the space (and the machine)

I am officially a Djangonaut! Joining the latest cohort (Session 6) of the Djangonaut Space program is very cool, and it means it's time to contribute back to the framework that I love and have been working with daily for the last 3.5 years: Django.

But, before I can start contributing with code, I need to get it running locally, setup a working local development environment and get its unit tests passing, to ensure that any future changes I make don't break something that I may not be aware of :D

While doing this, I encountered a few issues that I had to figure out, and this blog post is to discuss a bit how I overcame these issues on my machine which runs Fedora 43. If you're using another Linux-based distro, like Ubuntu, most of the tips here will help as well, you will just have to replace the dnf command with apt.

Step 0: Fork, clone and venv

To send code back to Django as future Pull Requests, first I need to create a "fork" of Django, which is a copy of its repository at https://github.com/django/django. To create the fork I just had to click on the "Fork" button on the top right of the django repo.

Once I had my own fork, I could clone it locally, by typing the following on my terminal

git clone git@github.com:rodbv/django.git
Enter fullscreen mode Exit fullscreen mode

Note that rodbv refers to my fork, it's my username on github. Replace with your own username!

Now I can start the instructions on how to run Unit Tests on the official documentation.

To isolate the libraries we install in their own environment, and not mess up with other programs in my machine, it's good to create a virtual environment, or venv.

After entering the directory I just created via clone, I ran

python -m venv venv
source venv/bin/activate
Enter fullscreen mode Exit fullscreen mode

Continuing with the instructions in the doc, I entered the tests directory where we'll run them:

cd tests
python -m pip install -e ..
python -m pip install -r requirements/py3.txt
Enter fullscreen mode Exit fullscreen mode

It started well for a few seconds, but then I got this

building 'pywatchman.bser' extension
creating build/temp.linux-x86_64-cpython-314/pywatchman
gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O3 -fPIC -I./pywatchman -I/usr/include/python3.14 -c pywatchman/bser.c -o build/temp.linux-x86_64-cpython-314/pywatchman/bser.o
error: command 'gcc' failed: No such file or directory
Enter fullscreen mode Exit fullscreen mode

The Art of Deciphering the Terminal

When working on a large codebase like Django, the terminal provides a wealth of information. Learning to get a deep breath and "read between the lines" of a long error message is a great skill for any contributor.

The key is looking at the very last command attempted. Here, the system tried to call gcc (the GNU C Compiler). The error No such file or directory simply means the tool isn't installed yet. Once the compiler is available, this error should go away

The fix:

sudo dnf install gcc
Enter fullscreen mode Exit fullscreen mode

That's sudo apt install gcc if you're on Ubuntu, Mint or Pop!OS

With the compiler ready, I tried again and encountered a new message:

Building wheel for pylibmc (pyproject.toml) ... error
  In file included from src/_pylibmcmodule.c:34:
  src/_pylibmcmodule.h:41:10: fatal error: Python.h: No such file or directory
     41 | #include <Python.h>
        |          ^~~~~~~~~~
  compilation terminated.
  error: command '/usr/sbin/gcc' failed with exit code 1
Enter fullscreen mode Exit fullscreen mode

How to read this:
Now we see that gcc is working perfectly, but it’s looking for Python.h. In C development, .h files are "headers", the interface that allows C code to interact with Python. Seeing this means you have the Python runtime, but you need the files used for building Python-linked applications.

I didn't know exactly what is the name of the dependency to install that would give me these .h files, but a quick trip to Google informed me that I should install this

sudo dnf install python3-devel
Enter fullscreen mode Exit fullscreen mode

Running the install command again, gave me this

src/_pylibmcmodule.c:36:12: fatal error: libmemcached/memcached.h: No such file or directory
     36 | #  include <libmemcached/memcached.h>
        |            ^~~~~~~~~~~~~~~~~~~~~~~~~~
Enter fullscreen mode Exit fullscreen mode

Ok, one more Google search and I see that I need to install memcached-devel

sudo dnf install libmemcached-devel
Enter fullscreen mode Exit fullscreen mode

I think you get the drift now. I had one more of these issues, in which the error looked like this

src/_pylibmcmodule.c:36:12: fatal error: zlib.h: No such file or directory
    36 | #  include <zlib.h>
       |            ^~~~~~~~
compilation terminated.
Enter fullscreen mode Exit fullscreen mode

...and the fix (again, with the help of Google) was to install zlib-devel.

I later learned that Fedora has a "shortcut" for many of these tools. Instead of installing gcc and other basics one by one, you can install a whole suite of building tools at once using:
sudo dnf groupinstall "Development Tools"
This is the Fedora equivalent of Ubuntu's build-essential and is a great time-saver for a fresh install

Victory: The Green Dots

After resolving the system dependencies, I ran the install command one last time. This time, instead of errors, I saw a beautiful cascade of successful installations:

Installing collected packages: PyYAML, pywatchman, pylibmc, Pillow, numpy, ...
Successfully installed MarkupSafe-3.0.3 Pillow-12.1.1 PyYAML-6.0.3 pylibmc-1.6.3 pywatchman-3.0.0 ...
Enter fullscreen mode Exit fullscreen mode

With the environment fully prepped, it was time for the moment of truth. I ran the test suite:

./runtests.py
Enter fullscreen mode Exit fullscreen mode

And I could finally see the tests running! Watching the terminal fill with dots as over 19,000 tests passed was incredibly rewarding.

Screenshot of Django tests passing, a sequence of thousands green dots and some

In the next post I will show you how I got to create a sample Django project and point to this local installation, and debug it using VS Code's awesome debugging tools :)

Cheers from Brazil!

Top comments (0)