What's the difference between setup.py and setup.cfg in python projects
Traditionally, setup.py
has been used to build a Python package, i.e.,
python setup.py build
Like any old Python file, setup.py
can contain lots of code. In most cases, however, it is purely declarative and simply lists package properties, e.g.,
from setuptools import setup
setup(
name="foobar",
version="0.1.0",
author="John Doe",
# ...
)
In fact, some consider it bad style to put much logic in setup.py
. To reflect that, setup.cfg
(which is declarative by design) has become more popular for packaging:
[metadata]
name = foobar
version = 0.1.0
author = John Doe
# ...
This has the advantage that the packaging software (e.g., setuptools) doesn't need to evaluate a Python file to get the meta data, but can simply parse a config file.
You can add a dummy setup.py
to that,
from setuptools import setup
if __name__ == "__main__":
setup()
or go full PEP 517/518 and instead add a pyproject.toml
.
[build-system]
requires = ["setuptools>=42", "wheel"]
build-backend = "setuptools.build_meta"
You can then build your projects using pypa-build (pip install build
) with
python3 -m build --sdist --wheel .
That being said, the landscape of Python packaging software is very much in motion at the moment (2019/20/21) and it is not clear which will be the preferred method of defining a Python package in the future. For example, there is PEP 621 which suggests to put package metadata into pyproject.toml
.
setup.py
is the file with the actual instructions how to build your software. These instructions might have some configuration options, e.g. for unit tests you might be able to indicate whether test coverage should be computed or not, or the install prefix etc.
setup.cfg
is a file which might be used to specify such options in addition to reading the command line when calling python setup.py <somecommand>
.
The documentation for setup.cfg
states:
Often, it’s not possible to write down everything needed to build a distribution a priori: you may need to get some information from the user, or from the user’s system, in order to proceed. As long as that information is fairly simple—a list of directories to search for C header files or libraries, for example—then providing a configuration file, setup.cfg, for users to edit is a cheap and easy way to solicit it. Configuration files also let you provide default values for any command option, which the installer can then override either on the command-line or by editing the config file.
setup.py
is an integral part of a python package which includes details or information about the files that should be a package. This includes the required dependencies for installation and functioning of your Python package, entry points, license, etc.
setup.cfg
on the other hand is more about the settings for any plug-ins or the type of distribution you wish to create. bdist/sdist and further classification of universal or core-python wheel. It can also be used to configure some meta-data of the setup.py
.