[Wheel-builders] Wheel files for PPC64le

[Nathaniel Smith]

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.

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.

-n

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