https://pantsbuild.org/ logo
#general
Title
# general
s

straight-action-80318

02/19/2023, 11:58 PM
Hey team, Is it expected that when you run
./pants generate-lockfiles
on a
requirements.txt
that has a link to a Github repo that the hash changes each time you run it? This is causing my repo to fail to run because when pex builds the lockfile the new hash doesn’t match the one in the file. An example is a requirements file that has this line
mosaicml-streaming@ git+<https://github.com/nharada1/streaming@decdc1f64bedcb483ff396ec9d96a1a939386ba7>
h

high-yak-85899

02/20/2023, 12:35 AM
If you don’t lock a hash in the requirements file, I’d expect it
Lock files are generated from scratch each time
e

enough-analyst-54434

02/20/2023, 12:38 AM
Well, that is a locked hash effectively, it points to a specific git sha. @straight-action-80318 can you present a diff of two of these lockfiles?
There are Pex lock integration tests over in Pex that assert locking is stable for VCS requirements that are also stable (I.E. that pin a sha); so this is surprising.
Try wrapping that
set
with
sorted
.
I assume that's the issue. Pex can't do anything about non-deterministic setup.py.
If that is it, maybe they'll accept a patch. That's pretty nasty behavior.
s

straight-action-80318

02/20/2023, 12:50 AM
Ah that’s a good find, yeah I worked around this by building the whl and hosting on S3 then pointing directly to that. I can try and submit a patch for mosaic on this one, thanks!
e

enough-analyst-54434

02/20/2023, 12:51 AM
Great. Please report back if that fix on your fork does or does not work.
s

straight-action-80318

02/20/2023, 1:01 AM
Yeah that does appear to fix it, great find!
e

enough-analyst-54434

02/20/2023, 1:04 AM
Excellent.
3 Views