[1/2] python3-installer: add installer module

Add a recipe for Installer, a minimal library/tool to install Python
Wheels.  Unlike PIP, it explicitly only installs wheels and does nothing
else.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 .../python/python3-installer_0.5.0.bb         | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3-installer_0.5.0.bb

Sorry to say that - but to me (even though it's more work) pip seems to 
be the better option - the proposed tool is ~8 months old and not part 
of pypa community as it seems - so in comparison to pip this could not 
be labeled "battle proven".

Especially as the second patch of the series removes the possibility to 
use the tooling proposed by python upstream for installing stuff.

If one would want to have that kind of tooling the switch from pure 
setup.py to toml and friends could have been done already a year ago 
(python-build was the originally proposed tool iirc) - so this feels to 
me like a step in the wrong direction (esp. the part that this would 
rely on a tool **not** supported by upstream)

On 10.03.22 18:16, Ross Burton wrote:
> Add a recipe for Installer, a minimal library/tool to install Python
> Wheels.  Unlike PIP, it explicitly only installs wheels and does nothing
> else.
> 
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>   .../python/python3-installer_0.5.0.bb         | 20 +++++++++++++++++++
>   1 file changed, 20 insertions(+)
>   create mode 100644 meta/recipes-devtools/python/python3-installer_0.5.0.bb
> 
> diff --git a/meta/recipes-devtools/python/python3-installer_0.5.0.bb b/meta/recipes-devtools/python/python3-installer_0.5.0.bb
> new file mode 100644
> index 0000000000..bde9397569
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3-installer_0.5.0.bb
> @@ -0,0 +1,20 @@
> +SUMMARY = "A library for installing Python wheels"
> +DESCRIPTION = "a low-level library for installing a Python package from a wheel distribution."
> +HOMEPAGE = "https://installer.readthedocs.io/"
> +BUGTRACKER = "https://github.com/pradyunsg/installer/issues"
> +
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=5038641aec7a77451e31da828ebfae00"
> +
> +SRC_URI[sha256sum] = "0cd6bdab3b358cf7e8749370b99aef9e12202751271c5ddb22126599b34dc665"
> +
> +inherit pypi flit_core
> +
> +DEPENDS:remove:class-native = "python3-installer-native"
> +DEPENDS:append:class-native = " unzip-native"
> +
> +do_install:class-native () {
> +    pip_install_wheel_do_bootstrap_install
> +}
> +
> +BBCLASSEXTEND = "native nativesdk"
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#163032): https://lists.openembedded.org/g/openembedded-core/message/163032
> Mute This Topic: https://lists.openembedded.org/mt/89691492/3647476
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [kweihmann@outlook.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On Thu, 10 Mar 2022 at 17:36, Konrad Weihmann <kweihmann@outlook.com> wrote:

> Sorry to say that - but to me (even though it's more work) pip seems to
> be the better option - the proposed tool is ~8 months old and not part
> of pypa community as it seems - so in comparison to pip this could not
> be labeled "battle proven".


It’s not that unheard of, for example the flit_core bootstrap documentation
says to use it:

https://flit.readthedocs.io/en/latest/bootstrap.html

It also does one job and just one job, which is A Very Good Thing.

Especially as the second patch of the series removes the possibility to
> use the tooling proposed by python upstream for installing stuff.


Do you mean Pip here? That’s one option.  Installing a wheel is a glorified
unzip, pip brings a lot of baggage that we don’t care about.

I should make it clear that this class is not for installing arbitrary
wheels, it installs a wheel we just built and in the future will build the
wheel too.

If one would want to have that kind of tooling the switch from pure
> setup.py to toml and friends could have been done already a year ago
> (python-build was the originally proposed tool iirc) - so this feels to
> me like a step in the wrong direction (esp. the part that this would
> rely on a tool **not** supported by upstream)


Adding support for build is next on the list.

Ross

On 10.03.22 19:25, Ross Burton wrote:
> 
> On Thu, 10 Mar 2022 at 17:36, Konrad Weihmann <kweihmann@outlook.com 
> <mailto:kweihmann@outlook.com>> wrote:
> 
>     Sorry to say that - but to me (even though it's more work) pip seems to
>     be the better option - the proposed tool is ~8 months old and not part
>     of pypa community as it seems - so in comparison to pip this could not
>     be labeled "battle proven".
> 
> 
> It’s not that unheard of, for example the flit_core bootstrap 
> documentation says to use it:
> 
> https://flit.readthedocs.io/en/latest/bootstrap.html 
> <https://flit.readthedocs.io/en/latest/bootstrap.html>
> 
> It also does one job and just one job, which is A Very Good Thing.

Still doesn't make it the best choice TBH.
Just diving into the code makes me wonder about a lot, like

- can this tool run on non arm/aarch64/x86/x86-64 hosts 
(https://github.com/pradyunsg/installer/blob/fad2894a572d5497a3dceec58407c276f21e8c11/src/installer/utils.py#L140) 
- in its full feature set? - the assumptions made by this function, 
makes me think, it doesn't
- support of this here https://github.com/pradyunsg/installer/issues/98, 
should be given by a matured tool

> 
>     Especially as the second patch of the series removes the possibility to
>     use the tooling proposed by python upstream for installing stuff.
> 
> 
> Do you mean Pip here? That’s one option.  Installing a wheel is a 
> glorified unzip, pip brings a lot of baggage that we don’t care about.
> 
> I should make it clear that this class is not for installing arbitrary 
> wheels, it installs a wheel we just built and in the future will build 
> the wheel too.

Then that's definitely missing in the commit message, that this should 
be an option and not the default

> 
>     If one would want to have that kind of tooling the switch from pure
>     setup.py to toml and friends could have been done already a year ago
>     (python-build was the originally proposed tool iirc) - so this feels to
>     me like a step in the wrong direction (esp. the part that this would
>     rely on a tool **not** supported by upstream)
> 
> 
> Adding support for build is next on the list.
> 
> Ross
> 

Anyway, I think in before this patch series the switch to wheels was 
good enough to work with it, now it's just introducing another tool - 
that doesn't feel right to me, but I will stop arguing about that

On Thu, 10 Mar 2022 at 19:03, Konrad Weihmann <kweihmann@outlook.com> wrote:
> > It also does one job and just one job, which is A Very Good Thing.
>
> Still doesn't make it the best choice TBH.
> Just diving into the code makes me wonder about a lot, like

Also referenced on https://github.com/brettcannon/mousebender, by a
prominent Microsoft Python engineer.

> - can this tool run on non arm/aarch64/x86/x86-64 hosts
> (https://github.com/pradyunsg/installer/blob/fad2894a572d5497a3dceec58407c276f21e8c11/src/installer/utils.py#L140)

Line 137 makes that moot, that's all Windows-specific.

> - support of this here https://github.com/pradyunsg/installer/issues/98,
> should be given by a matured tool

That's moot: it installs where the Python sysconfig module says to
install, which is told where to install when we build Python.

The Nix people want to override it per-package because they use
per-package prefixes, but we don't.  The prefix Python is built with
is the prefix we want to install into.

> > I should make it clear that this class is not for installing arbitrary
> > wheels, it installs a wheel we just built and in the future will build
> > the wheel too.
>
> Then that's definitely missing in the commit message, that this should
> be an option and not the default

If you want to install arbitrary packages with pip, then just use pip directly.

Ross

On Thu, 2022-03-10 at 17:16 +0000, Ross Burton wrote:
> Add a recipe for Installer, a minimal library/tool to install Python
> Wheels.  Unlike PIP, it explicitly only installs wheels and does nothing
> else.
> 
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>  .../python/python3-installer_0.5.0.bb         | 20 +++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 meta/recipes-devtools/python/python3-installer_0.5.0.bb
> 
> diff --git a/meta/recipes-devtools/python/python3-installer_0.5.0.bb b/meta/recipes-devtools/python/python3-installer_0.5.0.bb
> new file mode 100644
> index 0000000000..bde9397569
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3-installer_0.5.0.bb
> @@ -0,0 +1,20 @@
> +SUMMARY = "A library for installing Python wheels"
> +DESCRIPTION = "a low-level library for installing a Python package from a wheel distribution."
> +HOMEPAGE = "https://installer.readthedocs.io/"
> +BUGTRACKER = "https://github.com/pradyunsg/installer/issues"
> +
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=5038641aec7a77451e31da828ebfae00"
> +
> +SRC_URI[sha256sum] = "0cd6bdab3b358cf7e8749370b99aef9e12202751271c5ddb22126599b34dc665"
> +
> +inherit pypi flit_core
> +
> +DEPENDS:remove:class-native = "python3-installer-native"
> +DEPENDS:append:class-native = " unzip-native"
> +
> +do_install:class-native () {
> +    pip_install_wheel_do_bootstrap_install
> +}
> +
> +BBCLASSEXTEND = "native nativesdk"

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3273/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/3230/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/3243/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/3274/steps/14/logs/stdio

[missing maintainer entry]

Cheers,

Richard

On Thu, Mar 10, 2022 at 10:26 AM Ross Burton <ross@burtonini.com> wrote:

>
> On Thu, 10 Mar 2022 at 17:36, Konrad Weihmann <kweihmann@outlook.com>
> wrote:
>
>> Sorry to say that - but to me (even though it's more work) pip seems to
>> be the better option - the proposed tool is ~8 months old and not part
>> of pypa community as it seems - so in comparison to pip this could not
>> be labeled "battle proven".
>
>
> It’s not that unheard of, for example the flit_core bootstrap
> documentation says to use it:
>
> https://flit.readthedocs.io/en/latest/bootstrap.html
>
> It also does one job and just one job, which is A Very Good Thing.
>
>
And in fact, this was the first tool in my implementation. At the time it
was only a library and my awkward do_configure() cat << EOF scripts needed
to know the path to the wheel. It wasn’t gelled yet.

In the limited needs of oe-core, pip install “worked” (or seemed to) and so
that is what was submitted. To be clear, if we knew what we know now I
would never have used pip to install _our_ wheels. Never. It is a bloated
code base that wants to fetch your package, its dependencies, build them
all in a virtual environment and install them where it wants to install
things. It is entirely an end-user “desktop” tool.  This entire time, shoe
horning pip to do what we want has been a PITA.

Whether we switch to python3-installer now or later… I have little doubt we
will wish we had switched.


> Especially as the second patch of the series removes the possibility to
>> use the tooling proposed by python upstream for installing stuff.
>
>
> Do you mean Pip here? That’s one option.  Installing a wheel is a
> glorified unzip, pip brings a lot of baggage that we don’t care about.
>
> I should make it clear that this class is not for installing arbitrary
> wheels, it installs a wheel we just built and in the future will build the
> wheel too.
>
>
In fact, the pip_installer_wheel class opens the door to naive users
creating binary-only recipes to install random wheels from the internet.
There is ZERO chance we can support that workflow. Wheels will have
mismatched python ABI, glib, arch, etc. I have absolutely no intent to
answer any requests to do this. We build from source. You can write a
recipe on your own to use python3-pip-native to do this…here’s your spool
of rope. Good luck with your technical debt. You were warned not to do this.


> If one would want to have that kind of tooling the switch from pure
>> setup.py to toml and friends could have been done already a year ago
>> (python-build was the originally proposed tool iirc) - so this feels to
>> me like a step in the wrong direction (esp. the part that this would
>> rely on a tool **not** supported by upstream)
>
>
> Adding support for build is next on the list.
>

And would have already been in this implementation (with python3-build) if
only we could build a time machine. It just wasn’t ready yet. I was close…
the calendar said not close enough.


>
> Ross
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#163035):
> https://lists.openembedded.org/g/openembedded-core/message/163035
> Mute This Topic: https://lists.openembedded.org/mt/89691492/924729
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> ticotimo@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

On Thu, 10 Mar 2022 at 17:36, Konrad Weihmann <kweihmann@outlook.com> wrote:
> Sorry to say that - but to me (even though it's more work) pip seems to
> be the better option - the proposed tool is ~8 months old and not part
> of pypa community as it seems - so in comparison to pip this could not
> be labeled "battle proven".

FWIW, as of today installer is under pypa:

https://github.com/pypa/installer/commit/4495dea3baeab5e0f8059ca72b12ad7b91552832

Ross