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]> wrote: > > > > -----Original Message----- > > From: Leonardo Bianconi > > Sent: terça-feira, 14 de fevereiro de 2017 15:03 > > To: 'Nathaniel Smith' <[email protected]> > > Cc: Nick Coghlan <[email protected]>; [email protected] > > Subject: RE: [Wheel-builders] Wheel files for PPC64le > > > > > > > > > -----Original Message----- > > > From: Nathaniel Smith [mailto:[email protected]] > > > Sent: terça-feira, 14 de fevereiro de 2017 14:10 > > > To: Leonardo Bianconi <[email protected]> > > > Cc: Nick Coghlan <[email protected]>; [email protected] > > > Subject: Re: [Wheel-builders] Wheel files for PPC64le > > > > > > On Tue, Feb 14, 2017 at 5:11 AM, Leonardo Bianconi > > > <[email protected]> wrote: > > > > > > > > > > > >> -----Original Message----- > > > >> From: Nathaniel Smith [mailto:[email protected]] > > > >> Sent: terça-feira, 14 de fevereiro de 2017 06:31 > > > >> To: Nick Coghlan <[email protected]> > > > >> Cc: Leonardo Bianconi <[email protected]>; wheel- > > > >> [email protected] > > > >> Subject: Re: [Wheel-builders] Wheel files for PPC64le > > > >> > > > >> On Mon, Feb 13, 2017 at 2:54 AM, Nick Coghlan <[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
