[Wheel-builders] Wheel files for PPC64le

Mon Feb 20 15:08:01 EST 2017

Personally I try to avoid plans that require predicting the future years in
advance, but... It's kind of up to you? The name is not the most important
thing here :-).

A possible problem though is that I'm pretty sure centos doesn't support
ppc.

-n

On Feb 20, 2017 9:20 AM, "Leonardo Bianconi" <
leonardo.bianconi at eldorado.org.br> wrote:

>
>
> > -----Original Message-----
> > From: Leonardo Bianconi
> > Sent: terça-feira, 14 de fevereiro de 2017 15:03
> > To: 'Nathaniel Smith' <njs at pobox.com>
> > Cc: Nick Coghlan <ncoghlan at gmail.com>; wheel-builders at python.org
> > Subject: RE: [Wheel-builders] Wheel files for PPC64le
> >
> >
> >
> > > -----Original Message-----
> > > From: Nathaniel Smith [mailto:njs at pobox.com]
> > > Sent: terça-feira, 14 de fevereiro de 2017 14:10
> > > To: Leonardo Bianconi <leonardo.bianconi at eldorado.org.br>
> > > Cc: Nick Coghlan <ncoghlan at gmail.com>; wheel-builders at python.org
> > > Subject: Re: [Wheel-builders] Wheel files for PPC64le
> > >
> > > On Tue, Feb 14, 2017 at 5:11 AM, Leonardo Bianconi
> > > <leonardo.bianconi at eldorado.org.br> wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Nathaniel Smith [mailto:njs at pobox.com]
> > > >> Sent: terça-feira, 14 de fevereiro de 2017 06:31
> > > >> To: Nick Coghlan <ncoghlan at gmail.com>
> > > >> Cc: Leonardo Bianconi <leonardo.bianconi at eldorado.org.br>; wheel-
> > > >> builders at python.org
> > > >> Subject: Re: [Wheel-builders] Wheel files for PPC64le
> > > >>
> > > >> On Mon, Feb 13, 2017 at 2:54 AM, Nick Coghlan <ncoghlan at gmail.com>
> > > wrote:
> > > >> [...]
> > > >> > Sorry for the delayed reply (I've been travelling for the past
> few weeks
> > and
> > > >> > hence only intermittently polling various mailing lists).
> > > >> >
> > > >> > While your approach seems basically sound to me, the main
> challenge I
> > see
> > > >> > here is that it means the ppc64le manylinux1 build environment
> will be
> > > >> > starkly different from that for other architectures. That's not
> necessarily
> > > >> > an insurmountable problem, but it does mean that the main folks
> you
> > need
> > > >> > agreement from are the https://github.com/pypa/manylinux/
> > maintainers.
> > > >>
> > > >> I don't think we'd have any objections, but I don't think we'd be
> able
> > > >> to help much either. The current infrastructure for the manylinux
> > > >> docker images etc. is dependent on Travis-CI to run the builds, and
> > > >> Travis-CI obviously doesn't provide any support for ppc64le builds.
> So
> > > >> you're going to need your own PEP, your own image build scripts, and
> > > >> your own infrastructure to run them. The only thing that can
> obviously
> > > >> be shared is the pypa docker repository for distributing the final
> > > >> images; we can get you access there when you're ready if you do
> decide
> > > >> to go the docker route.
> > > >
> > > > There is the cross-compilation option as Nick mentioned
> > > > (https://mail.python.org/pipermail/wheel-builders/2017-
> > > January/000247.html),
> > > > The problem is that no tests can be run to ppc64le. Does Travis-CI
> run any
> > tests
> > > > currently?
> > >
> > > Well, there are two pieces here. We don't actually compile any
> > > manylinux wheels ourselves; we just provide the docker images as a
> > > convenience for developers who want to build manylinux wheels for
> > > their packages. So we use Travis-CI to build the docker images, and
> > > yeah, there are some rudimentary tests to make sure that the resulting
> > > binaries aren't totally broken. And then I expect (hope?) that most
> > > developers who use the docker images do some testing of the resulting
> > > binaries before distributing them, but really it's up to them. There
> > > isn't even any requirement that they have to use the docker images if
> > > they want to make manylinux wheels -- it's just a very convenient
> > > option.
> >
> > I didn't mean do not test it, I just wanted to know if some kind of tests
> > are being executed on Travis-CI.
> > Ok, now I got that it is related only with the Docker image, which
> probably
> > will need a ppc64le infrastructure, thanks!
> >
> > >
> > > In your case, it's kind of up to you how much hand-holding you want to
> > > give developers. In principle you could just write a PEP and then
> > > leave developers to figure out how to make the binaries. The downside
> > > though is that they probably won't do this, and I'm assuming you're
> > > here because you want there to actually be ppc64le binaries on pypi
> > > :-).
> > >
> > > As a package developer speaking personally I'd be *very* reluctant to
> > > distribute an untested cross-compiled binary for an architecture where
> > > my code had never been run.
> > >
> > > >> Possibly it would be less confusing to use a different name for
> these,
> > > >> like ppc64lelinux1 or something? If only to cut down on the number
> of
> > > >> times you have to explain why it's okay that ppc64le is still using
> > > >> manylinux1 when x86{,-64} has moved on to manylinux2.
> > > >
> > > > What would be the reason for the tag "manylinux1" be deprecated?
> > Shouldn't
> > > any
> > > > reason be applied for all architectures?
> > > > The only way I see it differ is if something change related with the
> base OS
> > > system,
> > > > as it is different for each one. But as we are using the same base
> library list, it
> > > > would be hard to happen, wouldn't it?
> > > > I have no objection on changing the name, I just would like to make
> things
> > > similar
> > > > for both arch, as would be easier for maintaining.
> > >
> > > In practice manylinux1 is "you must be compatible with RHEL5/CentOS5",
> > > since that's the oldest distro still in wide use. That's where the
> > > library versions in the manylinux1 spec come from.
> > >
> > > But RHEL5/CentOS5 are going out of support next month (hooray), so
> > > we'll probably be defining and transitioning to a manylinux2 based on
> > > RHEL6/CentOS6 very soon, where packages are allowed to assume newer
> > > versions of the base libraries.
> >
> > Right, based on this, I agree with you that the versions will be very
> different for
> > ppc64le, as it would not change for longer time.
> > What if we develop a tag for ppc64le with a version like "0.1", based on
> > RHEL7/CentOS7 (which has ppc64le support), until the current manylinux
> tag get
> > to the same OS version, i. e. RHEL7/CentOS7, so after that, the version
> can be
> > changed to be the same on both architectures? Or we could anticipate the
> > version for ppc64le to "3", which will be the version for the
> RHEL7/CentOS7, if
> > the OS version is the only reason to increase the tag version.
>
> any thoghts on this?
>
> >
> > >
> > > -n
> > >
> > > --
> > > Nathaniel J. Smith -- https://vorpus.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/wheel-builders/attachments/20170220/3e6d5b26/attachment-0001.html>