Re: [bitbake-devel] [PATCH 5/6] lib: Vendorize bundled third-party libraries under bb._vendor

Hi Ross,

I followed your advice and added support for vendoring:
https://github.com/robwoolley/bitbake/commits/vendoring/  Is this what you
had in mind?

I reviewed the patches for the vendored modules:

*beautifulsoup4*

   - most patches seemed to be for Python 3 support
   - I brought forward 2 patches into vendor/patches:
      - lib/bs4: Avoid soupsieve warning
      - lib: Remove double imports

*ply*

   - patches were all removed
   - some had been merged upgrade
   - patches related to FIPS issues in the signature function were no
   longer necessary due to refactoring upstream
   - ply is no longer maintained

*simplediff*

   - No changes were made, the version remains the same

*progressbar*

   - all 6 patches were refreshed


One drawback is that I had to add pyproject.toml for "vendoring sync ." to
work.  I wonder if this could cause confusion for people that expect it to
be a full Python project configuration file and try to use "python3 -m
build".

We may want to consider adding a complete pyproject.toml at the top-level.

Here are my testing instructions for anyone who wishes to follow along:
```
git clone -b vendoring https://github.com/robwoolley/bitbake
bitbake-vendoring
cd bitbake-vendoring
bin/bitbake-setup init poky-master
# Accept the options
# Source the build env:    .
/ala-lpggp31/rwoolley/bitbake-vendoring/bitbake-builds/poky-master/build/init-build-env
cd ../layers/bitbake
git remote add robwoolley https://github.com/robwoolley/bitbake
git remote update robwoolley
git checkout vendoring
cd $BUILDDIR
bitbake core-image-minimal
```

Regards,
Rob

On Thu, Apr 30, 2026 at 6:10 AM Ross Burton via lists.openembedded.org
<[email protected]> wrote:

> On 31 Mar 2026, at 15:53, Rob Woolley via lists.openembedded.org
> <[email protected]> wrote:
> >
> > Move ply, progressbar, simplediff, and bs4 from lib/ into
> > lib/bb/_vendor/ to avoid conflicts with system-installed versions
> > and to support proper packaging. These libraries contain local
> > modifications from their upstream versions.
>
> I’d like to see the vendoring done with a tool that lets us update the
> bundled libraries easily in the future, to be honest.
>
> When I wrote picobuild (now redundant as pypa/build can bootstrap itself)
> I used the same tool that pip uses to vendor its dependencies:
> https://github.com/pradyunsg/vendoring.  So
> https://gitlab.com/rossburton/picobuild is a minimal example of using
> vendoring: a few lines of configuration in pyproject.toml and a separate
> requirements file.
>
> Obviously if we sync from upstream we’ll drop our local changes, so the
> question then is why do we have forks?  Note that vendoring can apply
> patches when it updates, so if there’s a simple but not-upstreamable change
> we can carry the patch in-tree.
>
> Ross
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#19419):
> https://lists.openembedded.org/g/bitbake-devel/message/19419
> Mute This Topic: https://lists.openembedded.org/mt/118597577/556952
> Group Owner: [email protected]
> Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [
> [email protected]]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>