On Thu, Mar 10, 2022 at 11:38 AM Ross Burton <[email protected]> wrote:
> This is the last major change to the Python packaging before
> kirkstone, I promise! I think we should release with future-proof
> names instead of renaming everything the moment the LTS Kirkstone is
> released.
>
> Basically, I want to send this:
>
> --- b/meta/classes/pip_install_wheel.bbclass
> +++ b/meta/classes/python_pep517.bbclass
> -PIP_INSTALL_DIST_PATH ?= "${WORKDIR}/dist"
> +PEP517_WHEEL_PATH ?= "${WORKDIR}/dist"
>
> -PIP_INSTALL_PYTHON = "python3"
> -PIP_INSTALL_PYTHON:class-native = "nativepython3"
> +PEP517_INSTALL_PYTHON = "python3"
> +PEP517_INSTALL_PYTHON:class-native = "nativepython3"
>
> -INSTALL_WHEEL_COMPILE_BYTECODE ?= "--compile-bytecode=0"
> +PEP517_COMPILE_BYTECODE ?= "--compile-bytecode=0"
>
> The rationale being that pip_install_wheel doesn't have to use pip to
> install wheels (there is a patch to use installer, and the ability to
> change to something better would be nice), and in the future we plan
> to also cover the build stage (using python -mbuild). As this class
> hasn't actually been in a release yet, now is the time to change any
> names before they're locked into a LTS release.
>
My original plan was to use python3-build and python3-installer, because
they are simple tools to do one thing. That wasn’t quite ready at the
“feature freeze”. My more complex and naive approach “worked”, so I
submitted it. RP and I worked extremely long hours to get oe-core to
stabilize. But I tend to prefer this change, because this is likely where
we will be going in 3.6. This is where we wanted to go for 3.5.
While upstream python3-installer is not yet under the pypa umbrella, it
might very well move there soon. During the time this new packaging was
developed, flit moved under the pypa umbrella, as an example. The fact that
python3-installer now has a CLI (0.5.0 release) is a big help. it must also
be noted that python3-installer has the knobs we are used to (platlib and
friends). We are very much at the mercy of pip install knobs. They are not
quite what we need. Installation of wheels has been the most frustrating
and brittle aspect of this packaging change.
I had previous iterations with a pyprojecttoml.bbclass and a
pypa_installer.bbclass. The first is too long, the second is no more
obvious than pep517 (and limits to install). The intent has always to have
a one-stop class to “build and install” wheels in the way that we need that
to happen. It wasn’t until recently with a lot more experience that this
path forward became obvious.
The refactoring Ross has been doing (in constant communication with me the
entire time) is exactly what we needed. We would have done this a month ago
if life permitted what we want.
In short, I am aligned with the proposal to make the wheel “installer”
class more future proof. The naming of python_pep517 is as good as any.
—Tim
> I'm just building all of oe-core + meta-python with this to verify it
> works. Konrad, any thoughts?
>
> Ross
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163045):
https://lists.openembedded.org/g/openembedded-core/message/163045
Mute This Topic: https://lists.openembedded.org/mt/89694693/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
