Pypi packages + cibuildwheel: Hi, we're using cibu...
# general
m
Pypi packages + cibuildwheel: Hi, we're using cibuildwheel to pre-build wheels of third party dependencies that we use. When I use these wheels, I occasionally see a message like:
Copy code
Expected sha256 hash of db4db3c08ffbb18582f856545f058a7a5e4ab6f17f75795ca90b3c38ee0a8ba4 when downloading sqlalchemy but hashed to 87f49295ffab7bcf6808f9dacb451bf6b31410be53ba27b72564cc9efa971e34.
which I imagine is expected (since these are pre-built wheels, rather than sdists / released wheels).. Any thoughts on why this happens?
It doesn't happen all the time? Also, we're using Gitlab's "registry" as our internal pypi server
b
Which version of SQLAlchemy? Plus, can you see if either of those hashes appear in your lockfile?
m
Let me see what our "internal" built hash for that wheel is
Screenshot 2023-12-19 at 1.30.31 PM.png
(aside: we rebuild this wheel because it doesn't have a mac arm wheel available)
@broad-processor-92400 they both show up.. Let me see the context
🤔 1
It looks like the
artifacts
section for
sqlalchemy
has files from pypi and our "internal" registry
We have our registries configured as:
Copy code
[python-repos]
indexes = [
   # pypi passthrough and internal packages 
'<https://gitlab.com/api/v4/projects/><passthrough>/packages/pypi/simple',
  # internally built wheels of external projects '<https://gitlab.com/api/v4/projects/><internally_built_wheels>/packages/pypi/simple',
]
I'm going to try and shift ordering, but perhaps the
generate-lockfile
/
pip
is just throwing them all together into the lockfile?
Also, it doesn't happen consistently, so could be some sort of race-y condition
cc @curved-manchester-66006
Perhaps one workaround is just to use one index (with passthrough)..?
c
Now that I look at this I'm confused how the gitlab passthru works, I naivey would expect all the `url`s to be from gitlab and not pythonhosted
m
Good news: I think using https://docs.gitlab.com/ee/user/packages/pypi_repository/#install-from-the-group-level may be a quick fix on our part. There may (?) be another issue here, or this may be the "expected" result with having multiple indexes with the same package (but different hashes)