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.