Hello Wes,
I'm ok with option 2 when we use the yet unfinished manylinux2010 image as the
base. This way, we will still be able to produce wheels that in the near future
are actually based an a architecture tag supported by a PEP. Also as I have
some packaging nightmare, I would feel much bette
Just as a point of reference, I don't think that get any pushback at MapR
for not supporting RHEL 5 and that has been our policy for a few years now.
That experience should be pretty similar for Arrow, except that I would
expect that new adoptions might be even more canted towards current
versions
hi folks,
Surfacing a JIRA discussion ([4]) to the mailing list for discussion.
The manylinux1 ABI was developed to provide a mechanism for portable
Python packages with pre-compiled binary extensions supporting C and
C++, including C++11, on a wide variety of Linux distributions without
need for
