Hey team, Is it expected that when you run `./pan...
# general
s
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
If you don’t lock a hash in the requirements file, I’d expect it
Lock files are generated from scratch each time
e
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
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
Great. Please report back if that fix on your fork does or does not work.
s
Yeah that does appear to fix it, great find!
e
Excellent.