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