On Thu, Mar 10, 2022 at 10:26 AM Ross Burton <r...@burtonini.com> wrote:
> > On Thu, 10 Mar 2022 at 17:36, Konrad Weihmann <kweihm...@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 (#163046): https://lists.openembedded.org/g/openembedded-core/message/163046 Mute This Topic: https://lists.openembedded.org/mt/89691492/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
