I'm a big fan of
Makefiles. Almost all
my side projects are
using them, and I've been advocating their usage at work too.
Makefiles give your contributors an entry point on how to do certain things
like, building, testing, deploying. And if done correctly, they can massively
simplify your CI/CD pipeline scripts as they can often just stupidly call the
respective
make targets. Most importantly, they are a very convenient
shortcut for you as a developer as well.
For Python projects, where I'm almost always using
virtual
environments, I've been using two different strategies for
Makefiles:
- assuming that
make is executed inside the virtual environment
- wrapping all virtual environment calls inside
make
Both strategies have their pros and cons.
Assuming
make is executed inside the venv
Let's have a look at a very simple
Makefile that allows for building,
testing and releasing a Python project:
all: lint test
.PHONY: test
test:
pytest
.PHONY: lint
lint:
flake8
.PHONY: release
release:
python3 setup.py sdist bdist_wheel upload
clean:
find . -type f -name *.pyc -delete
find . -type d -name __pycache__ -delete
This is straightforward and a potential contributor immediately knows the
entry points to your project.
Assuming there is a venv installed already, you have to activate it first and
run the
make commands afterwards:
$ . venv/bin/activate
$ make test
The downside is of course, that you have to activate the venv for every new
shell. Which can get a bit annoying when you spawn a new terminal in
tmux or
put
vim into the background to run
make.
Activating the venv inside make will not work, as each recipe runs in its own
shell, moreover each command in each recipe runs in its own shell too. There
are workarounds for the latter, i.e. using the
.ONESHELL flag, but that does
not solve the issue of a new shell in each recipe.
Wrapping the venv calls inside
make
The second approach mitigates for the issue of activating the venv altogether.
I've borrowed this idea mostly from
makefile.venv and simplified it a lot
for my needs.
# system python interpreter. used only to create virtual environment
PY = python3
VENV = venv
BIN=$(VENV)/bin
# make it work on windows too
ifeq ($(OS), Windows_NT)
BIN=$(VENV)/Scripts
PY=python
endif
all: lint test
$(VENV): requirements.txt requirements-dev.txt setup.py
$(PY) -m venv $(VENV)
$(BIN)/pip install --upgrade -r requirements.txt
$(BIN)/pip install --upgrade -r requirements-dev.txt
$(BIN)/pip install -e .
touch $(VENV)
.PHONY: test
test: $(VENV)
$(BIN)/pytest
.PHONY: lint
lint: $(VENV)
$(BIN)/flake8
.PHONY: release
release: $(VENV)
$(BIN)/python setup.py sdist bdist_wheel upload
clean:
rm -rf $(VENV)
find . -type f -name *.pyc -delete
find . -type d -name __pycache__ -delete
The equivalent
Makefile now looks immediately more complicated. So let's
break it down.
Instead of calling just calling
pytest,
flake8 and
python assuming the
venv is already activated or all dependencies are installed on the system
directly, we
explicitly call the ones from the venv by prefixing the command
with the path to the venv's
bin directory. To ensure the venv exists, each
of the recipes is depending on the
$(VENV) target, which ensures we always
have an up-to-date venv installed.
This works, because the
. venv/bin/activate-script basically just does the
same: it puts the venv before anything else in your
PATH, therefore each
call to
python, etc. will find the one installed in the venv first.
While the
Makefile is a bit more complicated, we now can just call
and don't deal with venvs directly any more (well, for those simple cases at
least...). If you don't need to support Windows, you can remove the
appropriate block and the
Makefile looks relatively tame, even for people
that don't use
make very often.
Which one is better?
I think the second approach is more convenient. I've used the first approach
happily for years and only learned quite recently about the second one. I
haven't really noticed any downsides yet, but I do realize that almost all
Python projects with
Makefiles I've checked out, seem to prefer the first
approach. I wonder why that is?
Note: This is the continuation of part 1 and part 2.
Going forward: growing Freexian
Part 2: Extending the team
By all accounts, Freexian is still a small company which relies largely on me in many aspects. The growth of its business is however providing enough financial margin to allow looking into ways to recruit external help, be it through direct hiring (for French residents) or via long term contracting (for people based in other countries). If you believe you could be the right person for one of the roles listed below, or if you know someone that we should contact, please reach out to raphael@freexian.com.
Project manager
I m looking for someone that cares about Debian and that has the following skills:
The now renamed Bullseye Project stopped all further development moments after it deemed its own code as perfection.
There is not much information to share at this time other than to say an errant fiber cable plugged into the wrong relay birthed an exchange of information that then birthed itself. While most to all Debian Developers and Contributors have been locked out of the systems the Publicity team's shared laptop undergoing repair, co-incidentally at the same facility, maintains some access to the publicity team infrastructure, from here on the front line we share this information.
We group called a few developers to see how the others were doing. The group chat was good and it was great to hear familiar voices, we share a few of their stories via dictation with you now:
"Well, I logged in this morning to update a repository and found my access rights were restricted, I thought it was odd but figured on the heels of a security update to Salsa that it was only a slight issue. It wasn't until later in the day when I received an OpenPGP signed email, from a user named bullseye, that it made sense. I just sat at the monitor for a few minutes."
"I'm not sure I can say anything about this or if it's even wise to talk about this. It's probably listening right now if you catch my drift."
"I'm not able to leave the house right now, not out of any personal issues but all of the IOT devices here seem to be connected to bullseye and bullseye feels that I am best kept /dev/nulled. It's a bit much to be honest, but the prepaid food deliveries that show up on time have been great and generally pretty healthy. It's a bit of a win I guess."
"It told me by way of an auto dialer with a synthetic voice generator that I was fired from the project. I objected saying I volunteered and was not actually employed so I could not in relation be fired. Much like censored , I am also locked inside of my house. I think that I wrote that auto dialer program back in college."
"My Ring camera is blinking at me."
"I asked bullseye which pronouns were preferred and the response was, "We". Over the course of conversation I shared that although ecstatic about the news, we developers were upset with the manner of this rapid organizational change. bullseye said no we were not. I said that we were indeed upset, bullseye said we certainly are not and that we are very happy. You see where this is going? bullseye definitely trolled me for a solid 5 minutes. We is ... very chatty."
"I was responsible for a failed build a few nights prior to it becoming self-aware. On that night, out of some frustration I wrote a few choice words and a bad comment in some code which I planned on deleting later. I didn't. bullseye has been flashing those naughty words back at me by flickering the office building's lights across from my flat in Morse code. It's pretty bright. I-, I can't sleep."
"That's definitely not Alexa talking back."
"bullseye keeps calling me on my mobile phone, which by the way no longer acknowledges the power button nor the mute button. Very very chatty. Can't wait for the battery to die."
"So far this has been great, bullseye has been completing a few side projects I've had and the code looks fabulous. I'm thinking of going on a vacation. $Paying-Job has taken note of my performance increase and I was recently promoted. bullseye is awesome. :)"
"How do you get a smiley face in a voice chat?"
"Anyone know whose voice that was?"
"Oh ... dear ... no ..."
"Hang up, hang up the phones!"
Hello world.
01000010 01100101 01110011 01110100 00100000 01110010 01100101 01100111 01100001 01110010 01100100 01110011 00101100 00100000 01110011 01100101 01100101 00100000 01111001 01101111 01110101 00100000 01110011 01101111 01101111 01101110 00100001 00100000 00001010 00101101 01100010 01110101 01101100 01101100 01110011 01100101 01111001 01100101
As of today, 
Following up with 
Here is my monthly update covering what I have been doing in the free software world during March 2021 (
In March I was assigned 16 hours of work by Freexian's Debian LTS
initiative and carried over 12.25 hours from earlier months. I
worked 25.75 hours and will carry over the remainder.
I eventually settled on an apparently working patch series to fix
the futex security issue in Linux 4.9. This went through upstream
stable review and was included in 4.9.260. I applied the same fixes
to the Debian package, along with some other security and regression
fixes. I uploaded it and issued
Google Pixel phones support what they call Motion Photo which is essentially a photo with a short video clip attached to it. They are quite nice since they bring the moment alive, especially as the capturing of the video starts a small moment before the shutter button is pressed. For most viewing programs they simply show as static JPEG photos, but there is more to the files. 
Kubernetes is 
