Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WHEEL file size mismatches for ortools-7.0.6546-cp36-cp36m-manylinux1_x86_64.whl #1218

Closed
georgi-yanchev opened this issue Apr 25, 2019 · 8 comments
Assignees
Labels
Bug Lang: Python Python wrapper issue
Milestone

Comments

@georgi-yanchev
Copy link

(.venv) root@5e15c7a622d4:~/project/aaa/ortools-7.0.6546.dist-info# ls -la WHEEL 
-rw-r--r-- 1 root root 109 Mar 25 14:55 WHEEL
(.venv) root@5e15c7a622d4:~/project/aaa/ortools-7.0.6546.dist-info# cat RECORD | fgrep WHEEL
ortools-7.0.6546.dist-info/WHEEL,sha256=opqqECzkr2EiaHB1f1oMkivXbaoa7jbdA_NbjmFJL1Y,112

Note that file WHEEL is of size 109, but in RECORD it's stated to be 112 bytes.

@Mizux Mizux added Bug Lang: Python Python wrapper issue labels Apr 26, 2019
@Mizux
Copy link
Collaborator

Mizux commented Apr 26, 2019

Is it an issue for you ? As i said in the release note we provide a "manylinux1" package while in reality it is a "manylinux10" so we modify the package meta using sed which would explain the size diff.

ref:

# Hack wheel file to rename it manylinux1 since manylinux2010 is still not
# supported by pip
FILE=(${EXPORT_ROOT}/*-${PYTAG}-*.whl)
unzip "$FILE" -d /tmp
sed -i 's/manylinux2010/manylinux1/' /tmp/ortools-*.dist-info/WHEEL
rm -f $FILE
WHEEL_FILE=${FILE//manylinux2010/manylinux1}
(cd /tmp; zip -r ${WHEEL_FILE} ortools ortools-*; rm -r ortools*)
echo "Wheel file: ${WHEEL_FILE}"

@Mizux
Copy link
Collaborator

Mizux commented Apr 26, 2019

note: Most distro have a glibc >= 2.12 so it's OK IMHO...

Packaging status

@georgi-yanchev
Copy link
Author

I'm not sure I understand your comment about glibc.

My project has a bunch of dependencies and or-tools is one of them. I'm packaging a PEX ( https://github.com/pantsbuild/pex ) executable and this file is the only one rejected by PEX build. That's how to reproduce the error:

root@91e8620481ff:~# pip install pex==1.6.6  
root@91e8620481ff:~# pip wheel ortools==7.0.6546
root@91e8620481ff:~# pex -o ort.pex ortools-7.0.6546-cp36-cp36m-manylinux1_x86_64.whl 
Traceback (most recent call last):
  File "/usr/local/bin/pex", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.6/dist-packages/pex/bin/pex.py", line 675, in main
    pex_builder = build_pex(reqs, options, resolver_options_builder)
  File "/usr/local/lib/python3.6/dist-packages/pex/bin/pex.py", line 608, in build_pex
    pex_builder.add_distribution(resolved_dist.distribution)
  File "/usr/local/lib/python3.6/dist-packages/pex/pex_builder.py", line 336, in add_distribution
    dist_hash = self._add_dist_zip(dist.location, dist_name)
  File "/usr/local/lib/python3.6/dist-packages/pex/pex_builder.py", line 301, in _add_dist_zip
    wf.install(overrides=self._get_installer_paths(whltmp), force=True)
  File "/usr/local/lib/python3.6/dist-packages/pex/vendor/_vendored/wheel/wheel/install.py", line 289, in install
    if self.parsed_wheel_info['Root-Is-Purelib'] == 'true':
  File "/usr/local/lib/python3.6/dist-packages/pex/vendor/_vendored/wheel/wheel/install.py", line 67, in __get__
    val = self.wrapped(inst)
  File "/usr/local/lib/python3.6/dist-packages/pex/vendor/_vendored/wheel/wheel/install.py", line 259, in parsed_wheel_info
    return read_pkg_info_bytes(self.zipfile.read(self.wheelinfo_name))
  File "/usr/lib/python3.6/zipfile.py", line 1338, in read
    return fp.read()
  File "/usr/lib/python3.6/zipfile.py", line 858, in read
    buf += self._read1(self.MAX_N)
  File "/usr/lib/python3.6/zipfile.py", line 962, in _read1
    self._update_crc(data)
  File "/usr/local/lib/python3.6/dist-packages/pex/vendor/_vendored/wheel/wheel/install.py", line 493, in _update_crc
    raise BadWheelFile("Bad hash for file %r" % ef.name)
pex.vendor._vendored.wheel.wheel.install.BadWheelFile: Bad hash for file 'ortools-7.0.6546.dist-info/WHEEL'

@Mizux
Copy link
Collaborator

Mizux commented Apr 26, 2019

manylinux1 defined by PEP513 require GLIBC <= 2.5 while abseil-cpp (OR-Tools dependency) require GLIBC >= 2.12 -> we can't technically provide a manylinux1 package.

So we used a manylinux2010 (PEP 571) proposal docker container to build a manylinux2010 package.
Unfortunately, while we can generate a manylinux2010 more or less, only few distro have a pip package up to date to support the manylinux2010 platform tag (as well as pypi.org didn't support it until recently) BUT since most distro have recent glibc (hey we are in 2019) so in practice providing a fake manylinux1 package which as been compiled against a recent glibc (2.12) just work...

Unfortunately pex seems to be a little bit agressive on its check, what you can do since pex seems to be a pure python lib is to hack the /usr/local/lib/python3.6/dist-packages/pex/vendor/_vendored/wheel/wheel/install.py", line 493 so pex don't care anymore of this....

note: official manylinux2010 docker container has just been released last week (yup 9 years late ;) )
see pypa/manylinux#179 to follow the progress more specifically pypa/manylinux#279 provide the manylinux2010 docker image on April 10th 2019...
bonus: manylinux1 container doesn't work on recent distro for years since it uses a deprecated vsyscall see pypa/manylinux#158

@georgi-yanchev
Copy link
Author

Got it about libc and manylinux2010. It makes sense.

In my build script I've added an exception for or-tools and it's repacked to make the hashes match, so that's not a big issue for me. I was just wondering if you want to patch RECORD, just like you patched WHEEL and have a package with matching hash sums.

@Mizux
Copy link
Collaborator

Mizux commented Apr 26, 2019

For sure, i'm not against this idea, just need to see if i can take time to do it.
I mean hack our manylinux.sh script to patch the RECORD and why not try to pex the package file to verify everything is good.

@Mizux Mizux self-assigned this Apr 26, 2019
@Mizux Mizux added this to the v7.1 milestone Apr 26, 2019
@georgi-yanchev
Copy link
Author

I created a PR for this: #1222

@lperron
Copy link
Collaborator

lperron commented Apr 26, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Lang: Python Python wrapper issue
Projects
None yet
Development

No branches or pull requests

3 participants