No hash found for file 'LICENSES_bundled.txt'

[sethfischer]

cadquery-ocp 7.7.0a0 has a missing or invalid hash for LICENSES_bundled.txt.

This can be demonstrated with the wheel command line tool:

$ wheel unpack cadquery_ocp-7.7.0a0-cp311-cp311-manylinux_2_31_x86_64.whl 
Unpacking to: cadquery_ocp-7.7.0a0...No hash found for file 'LICENSES_bundled.txt'

And it also presents as an error when attempting to install with Poetry 1.4.0:

$ poetry add --allow-prereleases cadquery-ocp
Using version ^7.7.0a0 for cadquery-ocp

Updating dependencies
Resolving dependencies... (0.1s)

Writing lock file

Package operations: 1 install, 0 updates, 0 removals

  • Installing cadquery-ocp (7.7.0a0): Failed

  AssertionError

  In cadquery_ocp-7.7.0a0-cp39-cp39-manylinux_2_31_x86_64.whl, LICENSES_bundled.txt is not mentioned in RECORD

  at ~/.local/share/pypoetry/venv/lib/python3.8/site-packages/installer/sources.py:158 in get_contents
      154│             if item.filename[-1:] == "/":  # looks like a directory
      155│                 continue
      156│ 
      157│             record = record_mapping.pop(item.filename, None)
    → 158│             assert record is not None, "In {}, {} is not mentioned in RECORD".format(
      159│                 self._zipfile.filename,
      160│                 item.filename,
      161│             )  # should not happen for valid wheels
      162│ 

Poetry 1.4.0 introduces a "modern installer" which verifies hashes. The modern installer can be disabled with:

poetry config --local installer.modern-installation false

which writes to poetry.toml in the project directory:

[installer]
modern-installation = false

Pip does not check hashes in wheel RECORD contents during installation, see pypa/pip#4705 which is currently triaged as a bug.

Poetry is checking hashes in compliance with PEP 0427:

During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD.

[sethfischer]

One solution could be to:

1. Unpack the wheel with wheel unpack <wheel_file>.
2. Add the file LICENSES_bundled.txt to the unpacked wheel.
3. Repack the wheel with wheel pack which regenerates the RECORD file.

wheel pack <wheel_directory>:

This command can be used to repack a wheel file after its contents have been modified. This is the equivalent of zip -r except that it regenerates the RECORD file which contains hashes of all included files.

[jmwright]

@sethfischer I thought that at one point, this was already done in CI. Am I remembering that incorrectly @fpq473 ?

[fpq473]

@jmwright setup.py tries to figure out conda pkgs were bundled as part of the wheel, and generates a license file containing pkg metadata and licenses. This is being added incorrectly to the wheel; I have used @sethfischer's suggestion to implement a fix. I'll make a PR soon.

We also have a hard-coded LICENSES_bundled. Should we just delete that? It's possibly out-dated/incomplete compared to the generated one.

[fpq473]

See #13

[jmwright]

We also have a hard-coded LICENSES_bundled. Should we just delete that? It's possibly out-dated/incomplete compared to the generated one.

Yes, I agree with deleting the hard coded file as you have done in the PR. Thanks!

[jmwright]

@fpq473 We have ABI errors on the latest build.

[fpq473]

@jmwright Caused by a newer build (but same version, still 7.7.0) of occt:

(base) root@441705bc5025:/# conda search conda-forge:occt
Loading channels: done
# Name                       Version           Build  Channel             
...
occt                           7.7.0      h244afa2_1  conda-forge
occt                           7.7.0      h6cf717c_2  conda-forge
(base) root@441705bc5025:/# 

When we built 7.7.0a wheels successfully, the build picked up h244.

Now, the build is picking up h6cf, built with a newer compiler around Feb 7: https://github.com/conda-forge/occt-feedstock/commit/9eddd4a9f31300846a7b7079a383c83c1e60ff15

I'm not aware of a way of asking conda to install packages with constraints on compiler version, so we may have to pin the exact version (for Linux), e.g. conda install occt=7.7.0=h244afa2_1 in the action. What do you think?

[jmwright]

What do you think?

It sounds like pinning the exact version is our best (if not only) option.

[fpq473]

I committed 9dfc0c7d6d61f608252bfdf6e3643f18684847b3 and triggered the workflow.

The workflow file is getting pretty ugly. If anyone knows of a better way to make steps os-dependent, please share.

[fpq473]

@jmwright Build is all green.

@sethfischer Thanks for the report and suggestion.

[jmwright]

@fpq473 Thanks

[fpq473]

@jmwright Did you want to do a release? Looks like you tried to bump the version around Feb 27 (but those builds failed).

[jmwright]

@fpq473 Sure, but it might be a while before I get a chance. If you want to create a lightweight tag named 7.7.0a1 and push it, the GitHub Action should take care of the rest.

[jmwright]

Thanks to @fpq473 this was fixed in the latest build. https://pypi.org/project/cadquery-ocp/7.7.0/

@fpq473 I forgot that the version number is pulled from the Conda version, which is already at 7.7.0, so I pushed a 7.7.0a1 tag that really had no effect other than triggering a publish for 7.7.0.