[Wheel-builders] Wheel files for PPC64le

[Leonardo Bianconi]

> -----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