CentOS supports PPC64 and PPC64le, which the last, is the one probably will be the base for the tag (http://mirror.centos.org/altarch/7/isos/ppc64le/).
Thanks for the help, I will write a draft and send to the list. From: Nathaniel Smith [mailto:[email protected]] Sent: segunda-feira, 20 de fevereiro de 2017 17:08 To: Leonardo Bianconi <[email protected]> Cc: Nick Coghlan <[email protected]>; [email protected] Subject: RE: [Wheel-builders] Wheel files for PPC64le 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" <[email protected]<mailto:[email protected]>> wrote: > -----Original Message----- > From: Leonardo Bianconi > Sent: terça-feira, 14 de fevereiro de 2017 15:03 > To: 'Nathaniel Smith' <[email protected]<mailto:[email protected]>> > Cc: Nick Coghlan <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > Subject: RE: [Wheel-builders] Wheel files for PPC64le > > > > > -----Original Message----- > > From: Nathaniel Smith [mailto:[email protected]<mailto:[email protected]>] > > Sent: terça-feira, 14 de fevereiro de 2017 14:10 > > To: Leonardo Bianconi > > <[email protected]<mailto:[email protected]>> > > Cc: Nick Coghlan <[email protected]<mailto:[email protected]>>; > > [email protected]<mailto:[email protected]> > > Subject: Re: [Wheel-builders] Wheel files for PPC64le > > > > On Tue, Feb 14, 2017 at 5:11 AM, Leonardo Bianconi > > <[email protected]<mailto:[email protected]>> > > wrote: > > > > > > > > >> -----Original Message----- > > >> From: Nathaniel Smith [mailto:[email protected]<mailto:[email protected]>] > > >> Sent: terça-feira, 14 de fevereiro de 2017 06:31 > > >> To: Nick Coghlan <[email protected]<mailto:[email protected]>> > > >> Cc: Leonardo Bianconi > > >> <[email protected]<mailto:[email protected]>>; > > >> wheel- > > >> [email protected]<mailto:[email protected]> > > >> Subject: Re: [Wheel-builders] Wheel files for PPC64le > > >> > > >> On Mon, Feb 13, 2017 at 2:54 AM, Nick Coghlan > > >> <[email protected]<mailto:[email protected]>> > > 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
_______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
