https://pantsbuild.org/ logo
Powered by
b

brash-baker-91190

10/28/2021, 5:19 PM
I'm updating to version 2.8.0rc0 and running into this error:
Copy code
Traceback (most recent call last):
  File "/home/maier/.cache/pants/setup/bootstrap-Linux-x86_64/2.8.0rc0_py37/lib/python3.7/site-packages/pants/engine/internals/selectors.py", line 711, in native_engine_generator_send
    res = func.send(arg)
  File "/home/maier/.cache/pants/setup/bootstrap-Linux-x86_64/2.8.0rc0_py37/lib/python3.7/site-packages/pants/backend/python/util_rules/pex.py", line 441, in build_pex
    resolve_name,
  File "/home/maier/.cache/pants/setup/bootstrap-Linux-x86_64/2.8.0rc0_py37/lib/python3.7/site-packages/pants/backend/python/util_rules/lockfile_metadata.py", line 126, in from_lockfile
    concrete_class = _concrete_metadata_classes[metadata["version"]]
KeyError: 'version'
This is when I'm trying to run 
./pants update-build-files
to update things. Has anyone run into this before?
f

fast-nail-55400

10/28/2021, 5:30 PM
this looks related to the python requirements lockfile support in 2.8 given that trace.
What version of Pants were you upgrading from?
b

brash-baker-91190

10/28/2021, 5:32 PM
2.7.0rc2
f

fast-nail-55400

10/28/2021, 5:37 PM
can you share your pants.toml?
(I tried replicating an upgrade in a new repo with just a 
python_library
but did not reproduce the error. So knowing what is configured will help.)
b

brash-baker-91190

10/28/2021, 5:48 PM
I'll DM it to you
removing a bunch of my custom version pins and lockfiles makes it work
(for mypy, isort, etc.)
f

fast-nail-55400

10/28/2021, 5:53 PM
my theory is that 2.7.x didn’t write a 
version
key into the lockfiles and 2.8.x expects it to be there
I reproduced the failure
fix should be to just assume version 1 or whatever we were calling the version of lockfiles used in 2.7.x if the 
version
key is not present in the lockfile metadata
I’ll work up a fix
for now, to work-around, just delete the lockfiles and re-run 
./pants generate-lockfiles
they’ll get re-generated with the 
version
key in the metadata
b

brash-baker-91190

10/28/2021, 5:59 PM
Sounds good; thanks!
f

fast-nail-55400

10/28/2021, 6:01 PM
cc @hundreds-father-404 if you have any thoughts here
h

hundreds-father-404

10/28/2021, 6:02 PM
cc @ancient-vegetable-10556, do you have a moment to fix the lockfile versioning scheme?
Thanks Chris for the report!
a

ancient-vegetable-10556

10/28/2021, 6:02 PM
Yeah, I can take a look at that
❤️ 1
b

brash-baker-91190

10/28/2021, 6:05 PM
Thanks everybody!
f

fast-nail-55400

10/28/2021, 6:08 PM
a

ancient-vegetable-10556

10/28/2021, 6:09 PM
reviewed
f

fast-nail-55400

10/28/2021, 6:09 PM
we should also add a fix to 2.7.x to add the 
version: 1
h

hundreds-father-404

10/28/2021, 6:10 PM
2.7 does that, I think it's because of using 2.7.0rc2. The 
version
mechanism was added in 2.7.0rc3 because we wanted it before stabilizing tool lockfiles
Oh but technically I think going from 2.7.0rc2 to 2.70rc3 would fail @ancient-vegetable-10556? So we should cherry-pick to 2.7 and 2.8?
a

ancient-vegetable-10556

10/28/2021, 6:12 PM
Yeah, that sounds right.
To be clear, 2.7.x adds the version key, and reads always succeeded regardless of whether the version key was there
👍 1
6 Views
Powered by