[Distutils] Re: Linux binary wheels?
How does this proposal differ from manylinux2010? https://github.com/pypa/manylinux/blob/master/README.rst#example PEP 513: manylinux1 https://www.python.org/dev/peps/pep-0513/ PEP 571: The manylinux2010 Platform Tag (latest, as of 2019) https://www.python.org/dev/peps/pep-0571/ On Monday, August 19, 2019, Dan Stromberg wrote: > Hi folks. > I have a pair of ideas about Linux binary wheels, which are currently (I > heard) unsupported. > It seems like it should be possible to support Linux binary wheels using > one or both of these technologies: > * https://build.opensuse.org/ is a service that builds packages for a > variety of Linuxes > * Docker could be used to automate the building of wheels for a handful of > Linuxes with minimal dependencies. It seems like if you get > Debian/Ubuntu/Mint, Fedora/CentOS, openSUSE and perhaps one or two others, > that would cover almost all Linuxes and Linux users. > > I'm up to my hears in commitments already, but I sincerely someone will > grab onto one or both of these possibilities and run with them. > Thanks for reading. > > -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/HN7KH55YBWV2PCGKZBI23NAYWLW5OQQI/
[Distutils] Linux binary wheels?
Hi folks. I have a pair of ideas about Linux binary wheels, which are currently (I heard) unsupported. It seems like it should be possible to support Linux binary wheels using one or both of these technologies: * https://build.opensuse.org/ is a service that builds packages for a variety of Linuxes * Docker could be used to automate the building of wheels for a handful of Linuxes with minimal dependencies. It seems like if you get Debian/Ubuntu/Mint, Fedora/CentOS, openSUSE and perhaps one or two others, that would cover almost all Linuxes and Linux users. I'm up to my hears in commitments already, but I sincerely someone will grab onto one or both of these possibilities and run with them. Thanks for reading. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/SHS4MM5K55F2UKXGPWBCC55HNVIAPN5V/
[Distutils] Re: Adding support for adequately tagging AIX (pep425) to support distributed wheels
I guess the key question is what level of support is required to add support upstream for something versus trying to provide some way to hook into packaging so that upstream doesn't have to try and support every platform people run on? And it might come down to having Python having a way to specify it for the builds on those OSs such that packaging.tags picks it up appropriately. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/UJHZI256CBEWBGBEWLDAIVNU5LBDYNAL/
[Distutils] timeline for new pip resolver rollout - feedback?
What timeline are we thinking is realistic for rolling out the new pip resolver? (latest update on resolver work: https://pradyunsg.me/blog/2019/08/06/pip-update-2/ ) I'm re-upping this question which I originally asked on a GitHub issue about the rollout: https://github.com/pypa/pip/issues/6536#issuecomment-521696430 and would prefer to corral answers there. This depends a lot on Pradyun's health and free time, and code review availability from other pip maintainers, and whether we get some grants we're applying for, but I think the sequence is something like: 1) build logic refactor: in progress, done sometime December-February 2) UX research and design, test infrastructure building, talking to downstreams and users about config flags and transition schedules: we need funding for this; earliest start is probably December, will take 2-3 months 3) introduce the abstractions defined in resolvelib/zazo while doing alpha testing: will take a few months, so, conservatively estimating, May 2020? 4) adopting better dependency resolution and do beta testing: ? Is this right? What am I missing? I ask because some of the info-gathering work is stuff a project manager and/or UX researcher should do, in my opinion, and because some progress on the increase in metadata strictness https://github.com/pypa/packaging-problems/issues/264 and other issues might help with concerns people have brought up here. -- Sumana Harihareswara PyPI project manager, PyPA member & coordinator, and person who seems to write a lot of grant applications Changeset Consulting https://changeset.nyc -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/6SMATLMGYPKV4JHCF5NKVKJJRW2BDMJK/
[Distutils] Re: distutils.util.get_host_platform() and AIX
Resending since I messed up the reply. On Sun, 18 Aug 2019 at 8:29 PM, Michael wrote: > Would be 'nice' if old meant 3.6 and earlier as I would like to target 3.7 > and later. > I understand we're talking about generating the PEP 425 tags here. If not, please ignore this next paragraph. The "algorithm" essentially needs to be a check for "is this an AIX python" and also generate/provide a signal of what the system/binary compatibility looks like. This algorithm would executed on a target Python interpreter (which can be anything from Python 2.7, 3.3, 3.7 or a hypothetical 3.10), to check if that interpreter compatible with whatever tag you plan to generate. Reiterating - continue only here, or expand and include python-dev? > Continue here. python-dev has, practically, delegated Packaging discussions to this list. (opinion) If you're okay with changing communication channel, I have a strong preference for using discuss.python.org/c/packaging instead. Anyway, most of the packaging-related discussions have been happening there lately. Cheers, Pradyun -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/archives/list/distutils-sig@python.org/message/KKNRPX2RH4WVK5ZEY4TOQPM24Y4CQOPP/ > -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/W4B7W4QYI3HXS37K4CRZLKQ7WXZQGJIQ/
[Distutils] Adding support for adequately tagging AIX (pep425) to support distributed wheels
Goal - using wheels rather than RPM and/or installp formats for
distributing binary modules
Why bother?
One reason (there are likely more) - using wheels means packages/modules
can be loaded in a virtualenv
rather than require they are first loaded in the system environment
using installp/rpm/yum (with root authority). This alone has been reason
enough for me to do the research.
Introduction
The use of pip and wheels is commonplace in the worlds of Linux, macOS
and Windows.
Not so for AIX. Not because it couldn't be commonplace.
The current situation for AIX is comparable to the initial issue Linux
was facing
when PEP513 was written:
"Currently, distribution of binary Python extensions for Windows and OS
X is straightforward. ...
For Linux, the situation is much more delicate. ...
Build tools using PEP 425 platform tags [3] do not track information
about the particular Linux distribution or installed system libraries,
and instead assign all wheels the too-vague linux_i686 or linux_x86_64
tags. Because of this ambiguity, ..."
The root cause for the *ambiguity* that Linux systems had is not the
ambiguity that AIX faces.
AIX has provided a consistent way to "tag" it's runtime environment
since at least 2007 (AIX 5.3 TL7).
Since that time IBM AIX has also *guaranteed* binary compatibility for
migration of applications
from old to new OS levels.
I would like to see these tags added - at a minimum that they can be
retrieved by something such as sysconfig.get_var('AIC_BLD_TAG'). It
would be "nice" to see sysconfig.get_platform() updated to include these
values from the running system.
Further, while pip related tools can add the "bitness" to the platform
tags I would like to see something added to the AIX get_platform() tag
(b32, ppc, aix32), (b64, ppc64, aix64) for 32 and 64 bit operations,
respectively - as that is a "running" environment attribute. Open to
other ideas on what the bitness tag should be. IMHO - anything is better
than nothing. Maybe this could be considered a bug rather than as a new
feature.
Thank you for your feedback.
Michael
signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/archives/list/distutils-sig@python.org/message/DVHVSY7HFAK6B6BASXER2FUGXZN567UY/
