[4/5] Add Python packaging files

This enables creating a pip package for PyPI with:

    python3 -m build

Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
---
 pyproject.toml |  3 +++
 setup.cfg      | 40 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 43 insertions(+)
 create mode 100644 pyproject.toml
 create mode 100644 setup.cfg

On Wed, 21 Jan 2026 at 03:47, Rob Woolley via lists.openembedded.org
<rob.woolley=windriver.com@lists.openembedded.org> wrote:
> +version = 2.16.0a1

There are other issues in setup.cfg, and the commit title should be:
'bitbake-setup: add pypi packaging', but before that I think we need
to consider the release strategy and version scheme for it, and get
RP's blessing :)

Here's what there is in terms of tags and branches, and from what I've
heard it is not easy to change:
https://git.openembedded.org/bitbake/

I guess, bitbake-setup would only be released from the master branch,
at least once when a new yocto release happens, at the point where
stable and master branches diverge. Those releases should match the
stable version, e.g. whinlatter release would have been 2.16.

Then the question I can't quite answer is, how to version something
from the master trunk? E.g. if we want to release from master right
now, what version would it have? Note that ideally it needs to contain
the short commit id, for traceability.

Alex

Hi Rob,

On 1/21/26 3:47 AM, Rob Woolley via lists.openembedded.org wrote:
> This enables creating a pip package for PyPI with:
> 
>      python3 -m build
> 
> Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
> ---
>   pyproject.toml |  3 +++
>   setup.cfg      | 40 ++++++++++++++++++++++++++++++++++++++++

Please migrate everything in setup.cfg into pyproject.toml, there's no 
reason to use an ancient mechanism. (This may require a more recent 
setuptools)

>   2 files changed, 43 insertions(+)
>   create mode 100644 pyproject.toml
>   create mode 100644 setup.cfg
> 
> diff --git a/pyproject.toml b/pyproject.toml
> new file mode 100644
> index 00000000..4aff98bb
> --- /dev/null
> +++ b/pyproject.toml
> @@ -0,0 +1,3 @@
> +[build-system]
> +requires = ["setuptools>=61.0.0", "wheel"]
> +build-backend = "setuptools.build_meta"
> diff --git a/setup.cfg b/setup.cfg
> new file mode 100644
> index 00000000..3eaa3c49
> --- /dev/null
> +++ b/setup.cfg
> @@ -0,0 +1,40 @@
> +[metadata]
> +name = bitbake-setup
> +version = 2.16.0a1

100% we are going to forget updating this field. I'm wondering if we 
cannot simply use setuptools_scm to have a dynamic version?

Or use the version from lib/bb/__init__.py?

> +author = OpenEmbedded BitBake Developers
> +author_email = bitbake-devel@lists.openembedded.org
> +description = bitbake-setup
> +long_description = file: README.md
> +long_description_content_type = text/markdown
> +url = https://github.com/openembedded/bitbake.git
> +license = "GPL-2.0-only and MIT"

Must be uppercase, so AND. c.f. 
https://spdx.github.io/spdx-spec/v2.2.2/SPDX-license-expressions/#d2-case-sensitivity

> +classifiers =
> +    Programming Language :: Python :: 3
> +    License :: OSI Approved :: MIT License
> +    License :: OSI Approved :: GNU General Public License v2 (GPLv2)

This is deprecated since PEP639, c.f. 
https://peps.python.org/pep-0639/#deprecate-license-classifiers

> +    Operating System :: POSIX :: Linux
> +
> +[options]
> +package_dir =
> +    = lib
> +packages = find:
> +include_package_data = True
> +zip_safe = False
> +python_requires = >=3.6

3.9.0 as reported in __init__.py.

> +py_modules = codegen
> +
> +install_requires =
> +    ; List any non-standard dependencies BitBake needs
> +    ; BitBake is mostly self-contained, but check its documentation
> +
> +[options.packages.find]
> +where = lib
> +include =
> +    bb*

Is this meant to match both lib/bb/ and lib/bblayers/ ?

Why not explicitly list both?

> +    bs4*

What is this supposed to match except lib/bs4/?

Cheers,
Quentin

Hi Alex, Rob,

On 1/21/26 10:41 AM, Alexander Kanavin via lists.openembedded.org wrote:
> On Wed, 21 Jan 2026 at 03:47, Rob Woolley via lists.openembedded.org
> <rob.woolley=windriver.com@lists.openembedded.org> wrote:
>> +version = 2.16.0a1
> 
> There are other issues in setup.cfg, and the commit title should be:
> 'bitbake-setup: add pypi packaging', but before that I think we need
> to consider the release strategy and version scheme for it, and get
> RP's blessing :)
> 
> Here's what there is in terms of tags and branches, and from what I've
> heard it is not easy to change:
> https://git.openembedded.org/bitbake/
> 
> I guess, bitbake-setup would only be released from the master branch,
> at least once when a new yocto release happens, at the point where
> stable and master branches diverge. Those releases should match the
> stable version, e.g. whinlatter release would have been 2.16.
> 
> Then the question I can't quite answer is, how to version something
> from the master trunk? E.g. if we want to release from master right
> now, what version would it have? Note that ideally it needs to contain
> the short commit id, for traceability.
> 

setuptools_scm should be able to handle that, see 
https://setuptools-scm.readthedocs.io/en/stable/usage/#default-versioning-scheme. 
I've yet to play with it (will try with 
https://github.com/yoctoproject/bmaptool/ in the next few weeks).

Note that as far as I could tell this means all versioned files in the 
repo are part of the sdist by default (but you can exclude them via 
MANIFEST.in).

The next question is whether we're planning to upload bitbake itself to 
PyPI in the future? If so, we need to be careful about the layout. 
Building two packages from the same git repo isn't that straightforward 
if I remember correctly so if we're moving things around, better 
anticipate this possibility so we don't have to move everything around 
again once we want to publish bitbake itself.

Cheers,
Quentin

Hi,

On Wed Jan 21, 2026 at 3:47 AM CET, Rob Woolley via lists.openembedded.org wrote:
> This enables creating a pip package for PyPI with:
>
>     python3 -m build
>
> Signed-off-by: Rob Woolley <rob.woolley@windriver.com>
> ---
>  pyproject.toml |  3 +++
>  setup.cfg      | 40 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 43 insertions(+)
>  create mode 100644 pyproject.toml
>  create mode 100644 setup.cfg
>
> diff --git a/pyproject.toml b/pyproject.toml
> new file mode 100644
> index 00000000..4aff98bb
> --- /dev/null
> +++ b/pyproject.toml
> @@ -0,0 +1,3 @@
> +[build-system]
> +requires = ["setuptools>=61.0.0", "wheel"]
> +build-backend = "setuptools.build_meta"
> diff --git a/setup.cfg b/setup.cfg
> new file mode 100644
> index 00000000..3eaa3c49
> --- /dev/null
> +++ b/setup.cfg
> @@ -0,0 +1,40 @@
> +[metadata]
> +name = bitbake-setup
> +version = 2.16.0a1
> +author = OpenEmbedded BitBake Developers
> +author_email = bitbake-devel@lists.openembedded.org
> +description = bitbake-setup
> +long_description = file: README.md

I don't think we have a README.md file? Perhaps
doc/bitbake-user-manual/bitbake-user-manual-environment-setup.rst would be a
better candidate here?

> +long_description_content_type = text/markdown

This would be text/x-rst then.

> +url = https://github.com/openembedded/bitbake.git

It should probably be https://git.openembedded.org/bitbake/? The github version
is supposed to be a mirror only I think.

Antonin

On Wed, 21 Jan 2026 at 11:02, Quentin Schulz via
lists.openembedded.org
<quentin.schulz=cherry.de@lists.openembedded.org> wrote:
> The next question is whether we're planning to upload bitbake itself to
> PyPI in the future? If so, we need to be careful about the layout.
> Building two packages from the same git repo isn't that straightforward
> if I remember correctly so if we're moving things around, better
> anticipate this possibility so we don't have to move everything around
> again once we want to publish bitbake itself.

The answer to publishing bitbake itself is a firm no.

That said, bitbake-setup packaging files still shouldn't be at the top
level. There should be a script that moves them into right place
before doing the packaging step, or ideally packaging should be
pointed to use a sub-directory.

Alex