Removing setup.cfg from my Python project
Yesterday, I posted about my adventure in learning to package and publish Python
code. My first try was successful; I created a command line utility that can now
be installed from TestPyPI. However, I had decided to use a setup.cfg file,
which is not really necessary since you could just move all necessary
information into the pyproject.toml. This is what I did.
As before, you can get my source using this command:
git clone https://git.astharoshe.net/python/astharoshe-hello.git/
(this article describes tag 1.0.3).
The project structure has not really changed much: I did not touch any source
files. I did delete the setup.cfg, of course, and I referenced my LICENSE and
README.md files in my pyproject.toml, as you can see here:
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
[project]
name = "astharoshe_hello"
version = "1.0.3"
description = "test/example/template project"
authors = [{name="astharoshe.net", email="bw@astharoshe.net"}]
license = {file = "LICENSE"}
classifiers = [
"Programming Language :: Python :: 3",
"License :: OSI Approved :: ISC License (ISCL)",
"Operating System :: OS Independent"
]
readme = "README.md"
dependencies = []
requires-python = ">=3.10"
[project.scripts]
astharoshe_hello = "astharoshe_hello.main:main"
Most parts have straight-forward corresponding entries, so switching to a pure
pyproject.toml structure was very simple. And since I do not intend to support
any old versions of Python (unless I must, for some reason), not having a
setup.cfg should not bring any disadvantages to me.
This change also now fixes the missing documentation, so that is also nice.
Conclusion
Getting rid of another file feels really good. It moves the needle closer to
"creating a new Python project is simple". I still could not do it again from
memory, but this is not expected when doing it for the first time.
I have also learned today that a pyproject.toml without an explicit
"build-backend" section falls back to using setuptools anyway, so I could even
forget that section, but the guide recommends adding it. I guess "explicit is
better than implicit", which I like. So while this information does not change
what I write, I at least feel encouraged that my choice of using setuptools as
the build backend really is some kind of default and therefore a good decision.
I have also played shortly with uv and it really goes into the right
direction. I am however not happy about it being written in Rust. This makes
installing it unnecessarily complicated when running on less supported systems
like my OpenBSD notebook - then again, I was positively delighted that my
Raspberry Pi could just download a pre-built wheel file, which made the
installation trivial. I like the performance and stability of Rust programs, but
am I weird to think that such fundamental tools should also be available in the
language it handles itself? Maybe someone will write a uv compatible replacement
in pure Python if uv itself is successful?