[Wheel-builders] Wheel files for PPC64le

[Leonardo Bianconi]

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

> 
> -n
> 
> --
> Nathaniel J. Smith -- https://vorpus.org