The Approach of Packaging Commitizen Debian Package

Recently I began to work on commitizen deb packaging. The approach I adopted is similiar to what I have done for involving poetry packaging. That being said, by following the git flow of debian packaging, packaging with gbp ,and packaging debs on Ubuntu via schroot to package commitizen as a deb.

Why Package Commitizen

Since I use commitizen everyday! commitizen is a command line tool to make git commit messages in a pre-define format, so you can automate more flows by re-levaraging the messages.

The Challenging

The packaging task is still work-in-progress. Some issues happened to me and I believe some of them are very typical. That said, it is very likely that the same issues may happen to you if you try to package a python deb.

Lack of Dependencies

decli, questionary, and pytest-freezegun are dependencies of commitizen. "Unfortunately", they have not been packaged in Debian yet. I need to package them first, so I can then provide the all necessary dependencies of commitizen by feeding --extra-package of gbp.

setup.py Is Required if You Are Packaging a Python Debian Package

Many Python projects are using pyproject.toml to manage their source code now. That said, those projects a.k.a. upstream projects do not use setup.py anymore. We may need to prepare a setup.py to prepare source packages.

For example, commitizen uses poetry to manage its source code with pyproject.toml. I surveyed some tools to convert the pyproject.toml of poetry into setup.py, but most of them seems outdated or not maintained for a while. In the end, I found poetry2setup and it seems to work properly.

When packaging questionsary, I noticed examples package is not included in the setup.py generated by poetry2setup and I need to manually review and edit setup.py. I don't blame poetry2setup since examples will be automatically "detectable" when importing python packages. This is because poetry is in "development mode" by default. That said, the local source packages will be treated as installed in site-package by default.

Troubleshooting and Lesson Learned

Here is the summary of tips that I learned after troubleshooting.

dh_make Should Fit Releases of Distributions

dh-make is a tool that converts source archives into Debian pack. It generates the canonical files of debian directory (see the backgroud knowledge of debian directory if you are not familiar with what this debian directory is used for) that fits the relavent tools released in the same release of the distribution.

For example, if you want to package a debian package in bullseye of Debian, it may be a good idea to use dh-make that new enough (or higher if the compatibility is ok) as the dh-make in bullseye.

This is especially import tip when packaging a python debian package because of python2/3 compatibility and EOL transition recent years.

Pay attention to the version of dh-make you used and the reference you read may be a good idea.

Difference Between the Repositories of Deian and Ubuntu

The packages in the pockets of the repositories between Debian and Ubuntu may differ. That said, you may be able to build a package in Debian/Ubuntu but you will fail with Ubuntu/Debian. If you have any issue, pay attention to align the building release of distribution and the target a.k.a. where the package is installed in release of distribution. Tools like schroot will help you switch in different userspaces of distribution. See packaging debs on Ubuntu via schroot.