Skip to content
This repository has been archived by the owner on May 30, 2023. It is now read-only.

[RFC] dev-lang/python-oem: use python from python-build-standalone project #1815

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[RFC] dev-lang/python-oem: use python from python-build-standalone project #1815

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 2 additions & 3 deletions dev-lang/python-oem/Manifest
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,2 @@
DIST Python-3.9.12.tar.xz 19740524 BLAKE2B 05f2469aa53ca36221ef4976b17bfde3e5b86afd5a8114e5a7fd899f975a8e55022555ef718d5352ab68de1b7b23865a0bf713768c9c2b30d591438c9a396d25 SHA512 081981901e14149748fd35228db0b3b1d96fef227ae7404f07b8bad0fda4b02649bf31c348c94aefdaf3327565d78f9489437c2c02f647b15d41376a27a23e97
DIST Python-3.9.12.tar.xz.asc 833 BLAKE2B 33436d0404a643215a8fd2b967ffd216201da24f374941bf65b888159ccfabcbe79b751eca2dd489b06605604338c8bbaab74aa10abbe4bcffaa54236301228e SHA512 dddaa27f8a29034f458edb6739398a5455c87fe37b6349e161865a9deedca118ffe9cb82663cc75bbe60b3b556399c0c6855f5262aac1fe90d36a3694fca65b2
DIST python-gentoo-patches-3.9.12.tar.xz 12848 BLAKE2B 5dd66fa94b136a463d2c4be3a5b7dfad770c3905467a1d81af02a35b2783ce7d614881c915ee8f8e764c1656963d6886d9c60c6e524f512e1bc496e42d01307b SHA512 07de63e47a8e547724099062239df8fcfd254f19d38be28131e6bbb094ffbab8483861fb6a5905e60d7fa7a1a5dc06785951fa31984ecad89516b0b742c47f91
DIST cpython-3.9.11+20220318-aarch64-unknown-linux-gnu-install_only.tar.gz 86614999 BLAKE2B a76cfaff74f52c30afeee4082fbf17f2beb9660e2240bd75a0bb97f7e76bb7de88664d87cfdfbec09dcf1638929c42bb0a1750a0ebd963c5a86b0efa6ff3b66d SHA512 0eb13bbe1c52a129c5a45824a5dd5be53a607257bf5e4cfbec3998e6ba113d4d0fd35e086117b3be3632109052111cab437dc80ad085b3122e1d13afa095a08e
DIST cpython-3.9.11+20220318-x86_64_v2-unknown-linux-gnu-install_only.tar.gz 51943652 BLAKE2B ae7ad6cb41b3d91e61989c20f120729319c42542a65b0b1c2e1a499a5f04adb1c0892c5d9e5e61ba196acde40c3a11cb83e379141a411bb47e60ccc7f3e28af0 SHA512 325504f94f5f51930a15799777e50ffb0d42eb1f074414d7281e681d04ee621a5d82978255b00fa3054240908b2ccae00c6f853261ef3c87a54fdd95cb18cad2
84 changes: 0 additions & 84 deletions dev-lang/python-oem/README.md
View file
Open in desktop

This file was deleted.

32 changes: 32 additions & 0 deletions dev-lang/python-oem/python-oem-3.9.11.ebuild
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Copyright 2022 Gentoo Authors
pothos marked this conversation as resolved.
Show resolved Hide resolved
# Distributed under the terms of the GNU General Public License v2

EAPI=8

DESCRIPTION="This project produces self-contained, highly-portable Python distributions."
HOMEPAGE="https://github.com/indygreg/python-build-standalone/"
SRC_URI="
amd64? ( https://github.com/indygreg/python-build-standalone/releases/download/20220318/cpython-3.9.11+20220318-x86_64_v2-unknown-linux-gnu-install_only.tar.gz )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are the binary releases, or? I think it's ok to use binary releases if we have some criteria but at the moment we normally compile from source (also possible for this project).
So that's more a general question worth discussing: under which circumstances are we fine consuming third-party binaries, and if it's an option, should we plan to do more of it to lower the maintenance burden and build times? E.g, there are binary releases for the Rust compiler or Go, why not use them, too?

Copy link
Contributor Author

@jepio jepio Apr 14, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes these are binary releases. Normally I prefer the build from source approach, but it wouldn't be possible to do that from the ebuild here:

The execution environment must have access to a Docker daemon (all build operations are performed in Docker containers for isolation from the host system).

Though we could rebuild from source and host the binaries for ourselves, and then consume them.

E.g, there are binary releases for the Rust compiler or Go, why not use them, too?

I would be for switching to dev-lang/rust-bin, the build times for it are ridiculous, and the rust compiler (including self bootstrap) is a major part of our SDK build time. For go we wouldn't have much benefit from using a pre-built toolchain.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also given that we can revisit the choice of where the python binaries come from when migrating to sysext, I'm fine consuming the published binaries in this case here.

About Rust, yeah, specially the LLVM compilation takes ages…

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rust cross-compilation support is something we handle in dev-lang/rust and would need to be ported. I haven't looked deeper.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, or use rustup to install the regular toolchain into the SDK

arm64? ( https://github.com/indygreg/python-build-standalone/releases/download/20220318/cpython-3.9.11+20220318-aarch64-unknown-linux-gnu-install_only.tar.gz )
"
PYVER=$(ver_cut 1-2)

# TODO: many more licenses are needed
LICENSE="PSF-2"
SLOT="${PYVER}"
KEYWORDS="amd64 arm64"

# TODO: minimal host dependencies, may be we can express those?
DEPEND=""
RDEPEND="${DEPEND}"
BDEPEND=""

S="${WORKDIR}"

src_install() {
dodir /usr/share/oem
cp -a ${S}/python ${ED}/usr/share/oem
find ${ED} -name 'lib*.a' -delete
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
find ${ED} -name 'lib*.a' -delete
find ${ED}/usr/share/oem/python/ -name 'lib*.a' -delete

dosym python3 /usr/share/oem/python/bin/python
dosym lib /usr/share/oem/python/lib64
}
216 changes: 0 additions & 216 deletions dev-lang/python-oem/python-oem-3.9.12.ebuild
View file
Open in desktop

This file was deleted.