FYI, I've started a discussion on the next manylinux spec here:
https://discuss.python.org/t/the-next-manylinux-specification/
On Thu, Dec 6, 2018 at 4:21 AM Nick Coghlan wrote:
> On Tue, 4 Dec 2018 at 23:51, Matthias Klose wrote:
> > On 30.11.18 19:10, Brett Cannon wrote:
> > > And just to
On Tue, 4 Dec 2018 at 23:51, Matthias Klose wrote:
> On 30.11.18 19:10, Brett Cannon wrote:
> > And just to double-check, I'm assuming we don't want to just jump straight
> > to distro tags and say if you're centos_6 compatible then you're fine? I
> > assume that would potentially over-reach on
On 30.11.18 19:10, Brett Cannon wrote:
> I think either approach works, but if we do go with a glibc-versioned tag
> that we make it explicit in the tag, e.g. `manylinux_glibc_{version}`. That
> way if we ever choose to support musl (for Alpine) we can.
>
> The one question I do have is how the
On Mon, 3 Dec 2018 at 15:30, Nick Coghlan wrote:
>
> On Mon, 3 Dec 2018 at 23:11, Paul Moore wrote:
> >
> > On Mon, 3 Dec 2018 at 12:16, Nick Coghlan wrote:
> > > P.S. Paul asked how we can have manylinux tags without updating PEP
> > > 425 to include them, and the answer is that the actual
On Mon, 3 Dec 2018 at 23:11, Paul Moore wrote:
>
> On Mon, 3 Dec 2018 at 12:16, Nick Coghlan wrote:
> > P.S. Paul asked how we can have manylinux tags without updating PEP
> > 425 to include them, and the answer is that the actual compatibility
> > tag spec is at
> >
On Mon, 3 Dec 2018 at 12:16, Nick Coghlan wrote:
> P.S. Paul asked how we can have manylinux tags without updating PEP
> 425 to include them, and the answer is that the actual compatibility
> tag spec is at
> https://packaging.python.org/specifications/platform-compatibility-tags/
> and that
On Fri, 30 Nov 2018 at 18:12, Nathaniel Smith wrote:
>
> We could do the Windows thing, and have a plain "manylinux" tag that means
> "any recent-ish glibc-based Linux". Today it would be defined to be "any
> distro newer than CentOS 6". When CentOS 6 goes out of service, we could
> tweak the
Hi,
On Sat, Dec 1, 2018 at 5:18 PM Thomas Kluyver wrote:
>
> Thanks Nathaniel for the explanation.
>
> On Sat, Dec 1, 2018, at 4:39 AM, Nathaniel Smith wrote:
> > So the proposal here is to refactor the spec to match how this
> > actually works: the official definition of a manylinux_${glibc
> >
On Sun, Dec 2, 2018 at 6:10 PM Robert T. McGibbon wrote:
> I suspect that *I* am one of the major reasons that the manylinux1 ->
> manylinux2010 transition has been unreasonably drawn out, rather than any
> particular design flaw in the versioning scheme (manylinux_{cardinal number}
> vs.
Hi,
As the original author of auditwheel and co-author of PEP 513, I figure I
should probably chime in.
I suspect that *I* am one of the major reasons that the manylinux1 ->
manylinux2010 transition has been unreasonably drawn out, rather than any
particular design flaw in the versioning scheme
On Fri, Nov 30, 2018 at 7:13 AM Thomas Kluyver wrote:
> Do we lose the ability for a system to explicitly declare that it is or isn't
> compatible with a given manylinux variant (via the _manylinux?
Good question.
Straw man: if _manylinux is importable, and
_manylinux.manylinux_compatible is
On Fri, Nov 30, 2018 at 7:35 AM Paul Moore wrote:
> Only Linux users can really answer this. But what I will say is that
> on Windows, anything other than the core system libraries must be
> bundled in the wheel (so, for example, Pillow bundles the various
> image handling DLLs). Manylinux (as I
On Fri, Nov 30, 2018 at 10:29 PM Paul Moore wrote:
>
> On Sat, 1 Dec 2018 at 04:42, Nathaniel Smith wrote:
> > How does this affect spec-writing? Well, we want to allow for non-pip
> > installers, so the part that pip does has to be specified. But pip's
> > part is really straightforward.
>
On Sat, 1 Dec 2018 at 04:42, Nathaniel Smith wrote:
> How does this affect spec-writing? Well, we want to allow for non-pip
> installers, so the part that pip does has to be specified. But pip's
> part is really straightforward.
[...]
> So the proposal here is to refactor the spec to match how
It sounds like I should explain better how things currently work :-).
The original manylinux1 spec is PEP 513. But of course it's just text
-- it's a useful reference, but it doesn't do much by itself. And when
we wrote it we had no idea how this would actually work out.
In practice, there are
h SONAMEs included in the following list:
.…
libglib-2.0.so.0
Does this mean that only tags down to 2.0 needs to be generated?
TP
Sent from Mail for Windows 10
From: Brett Cannon
Sent: 01 December 2018 02:12
To: Nathaniel Smith
Cc: distutils sig
Subject: [Distutils] Re: Idea: perennial many
I think either approach works, but if we do go with a glibc-versioned tag
that we make it explicit in the tag, e.g. `manylinux_glibc_{version}`. That
way if we ever choose to support musl (for Alpine) we can.
The one question I do have is how the compatibility tags will work for a
tagged
On 2018-11-30 15:35:10 + (+), Paul Moore wrote:
[...]
> I certainly don't want to spark any sort of flamewar here, but I
> do feel a certain wry amusement that the term "DLL Hell" was
> invented as a criticism of library management practices on
> Windows, and yet in this context, library
On Fri, 30 Nov 2018 at 08:12, Nathaniel Smith wrote:
>
> Hi all,
>
> The manylinux1 -> manylinux2010 transition has turned out to be very
> difficult. Timeline so far:
>
> March 2017: CentOS 5 went EOL
> April 2018: PEP 517 accepted
> May 2018: support for manylinux2010 lands in warehouse
>
I'll betray my lack of understanding of how ABIs work:
PEP 571 (manylinux2010) defines a set of libraries besides libc which
compatible wheels can safely link against, such as glib and libXrender.
Most of these are only versioned by the filename suffix (like .so.6),
while glibc and a few
Yes
On Fri, Nov 30, 2018 at 1:27 AM Paul Moore wrote:
>
> On Fri, 30 Nov 2018 at 09:22, Pradyun Gedam wrote:
> >
> >
> > On Fri, 30 Nov 2018 at 1:42 PM, Nathaniel Smith wrote:
> >>
> >> April 2018: PEP 517 accepted
> >
> >
> > I think you got the wrong PEP number.
>
> Should be 571, presumably?
On Fri, 30 Nov 2018 at 09:22, Pradyun Gedam wrote:
>
>
> On Fri, 30 Nov 2018 at 1:42 PM, Nathaniel Smith wrote:
>>
>> April 2018: PEP 517 accepted
>
>
> I think you got the wrong PEP number.
Should be 571, presumably?
Paul
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe
On Fri, 30 Nov 2018 at 1:42 PM, Nathaniel Smith wrote:
> April 2018: PEP 517 accepted
>
I think you got the wrong PEP number.
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
23 matches
Mail list logo
