lock update does not preserve "binary-ness" and errors out with artifact set changes

[cburroughs]

$ pex3 --version
2.1.160
$ cat __pip_args.txt 
--only-binary acryl-datahub
$ pex3 lock create '--indent=2'  --manylinux manylinux2014 --interpreter-constraint $'CPython==3.10.*' --style=universal --pip-version=23.3.2 --resolver-version pip-2020-resolver --target-system=linux --target-system=mac  -r __pip_args.txt acryl-datahub==0.12.0.5 ansicolors~=1.1.8 -o only.lock
$ pex3 lock update -p ansicolors only.lock 
Encountered 1 error updating only.lock:
1.) cp311-cp311-manylinux_2_37_x86_64: The locked requirement acryl-datahub==0.12.0.5 should have been undisturbed by the lock update, but its additional artifact set changed from:

to:
('https://files.pythonhosted.org/packages/93/9a/bb6a21624adf4bf81534c573a84976b4b17ac21bccae6b00f7e46ed8c1aa/acryl-datahub-0.12.0.5.tar.gz', Fingerprint(algorithm='sha256', hash='6b681b9a735450c0457957a66e1e2b075e662c1fee3fbb4f3a20a192215cd8b9'))

[jsirois]

@cburroughs I think you knew this couldn't work? As per the discussion in pantsbuild/pants#20364 (comment) the --only-binary is a Pip back door Pants is using that Pex knows nothing about; so Pex would need to become globally aware of / support --only-binary first class for this to work at all. That support would be general, and locks would only happen to get support as well.

That said, pex3 lock sync (see: #2334 (comment)) will support the backdoor since it will accept requirement files and that may be what you want to use anyhow.

[jsirois]

So, @cburroughs if you actually want 1st class --no-binary / --only-binary: #2343
If you instead actually just want pex3 lock sync: #2344

It would be good to comment on what you actually want so I can direct current effort. As it stands, I've been chipping away at pex3 lock sync (#2344).

[cburroughs]

I think you knew this couldn't work?

I knew there wasn't any mechanism to change --only/no-binary with update, but I hadn't realized the implication that it would prevent updateing lockfiles created with those settings.

If pex3 lock sync existed I would use that instead of the "sharp knife". (Both as Pex user and for the thinnest plumbing through Pants.)

[jsirois]

@cburroughs great, thanks. I'll continue as-is then and complete #2344 1st then. I will note that Pants current use of a lock file (invalid JSON) header, could / should be eliminated ¹ when switching to pex3 lock sync since that command will noop if that's the right thing to do.

Footnotes

1. It should have been eliminated long ago regardless of pex3 lock sync availability (https://github.com/pantsbuild/pants/issues/14281), but this perhaps makes it easier since, afact, there is no longer a need to store that data anywhere at all. ↩

[jsirois]

Ok, it's been too long. @cburroughs I interrupted myself with activities related to extracting Pex from https://github.com/pantsbuild and https://pantsbuild.org to https://github.com/pex-tool and https://docs.pex-tool.org but that's all wrapped up. I'm back on #2344 and should have that out for review by EOD. I'll invite you to that review - your feedback will be important to help ensure your needs will all be addressed there.

[jsirois]

This issue should now be addressed by #2343 and #2344, the latter of which is now released in Pex 2.3.0: https://github.com/pex-tool/pex/releases/tag/v2.3.0