In the ST2 repo, regenerating the lockfile with 2....
# development
In the ST2 repo, regenerating the lockfile with 2.15.0 works fine (the lockfile shows pex_version 2.1.111). But, it is failing on 2.16.0a0 (which
./pants help tools
shows is using pex 2.1.126). Any hints on debugging would be appreciated. error message in the🧵
Copy code
ProcessExecutionFailure: Process 'Generate lockfile for st2' failed with exit code 1.

Failed to import pip: No module named 'pip'

Download pip:
curl <> | python

<snip 2 more pip download errors>
<snip "running dist_info" and a bunch of "creating" and "writing" lines>

Could not gather lock metadata for 3 projects with source artifacts:
1. /tmp/pants-sandbox-9iomkx/.tmp/tmppu9xjjqs/usr.bin.python3.6m/ Executing /home/cognifloyd/.cache/pants/named_caches/pex_root/venvs/52748ab20d11c253b0b94c5711d08220c8d6e353/5985ed09b49a653d6596b0e14d134c5456cf1a9f/bin/python -sE /home/cognifloyd/.cache/pants/named_caches/pex_root/venvs/52748ab20d11c253b0b94c5711d08220c8d6e353/5985ed09b49a653d6596b0e14d134c5456cf1a9f/pex -c import sys

import setuptools.build_meta

if not hasattr(setuptools.build_meta.__legacy__, 'prepare_metadata_for_build_wheel'):

result = setuptools.build_meta.__legacy__.prepare_metadata_for_build_wheel(*('/tmp/pants-sandbox-9iomkx/.tmp/tmp5fg3n042/build',), **{})
with open('/tmp/pants-sandbox-9iomkx/.tmp/tmpgryhk1b5', "w") as fp:
 failed with 1
<snip 2 other equivalent error messages but for different zips>

Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.
The 3 projects pex seems to be choking on are vcs requirements that, in this case, contain first party code. So I can change those other repos if needed (for now they need to remain vcs requirements as changing that is more than I want to tackle with the st2 infra in its current state).
Here are those requirements:
Copy code
st2-auth-backend-flat-file @ git+<>
st2-auth-ldap @ git+<>
st2-rbac-backend @ git+<>
Oh crap. The initial error comes from a stupid thing that those git repos call in @enough-analyst-54434 assuming that pip is installed is a bad assumption, right?
Correct. That is frankly doing a lot of crazy looking things. Are you 100% sure your needs are that far off brand to need all that?
I consider that stuff legacy crap… I want to delete all of these hand-crafted files. Eventually, I’ll bring pants to tame the other st2 repos, for now, they need to limp along until pants can bless them with sanity.
Ok, well if you don't want to change those repos much, adding a pep-518 pyproject.toml with your build requirements (Pip) probably makes sense.
I was able to rip out some of the screwy stuff in those files. Now regenerating the lockfile works just fine.
I hate non-declarative files!
I am facing a very similiar issue suddenly :
Copy code
Could not gather lock metadata for 1 project with source artifacts:
1. /tmp/pants-sandbox-Fusvjh/.tmp/tmp6341hm_u/myorg.dist.export.python.virtualenvs.default.3.8.16.bin.python3.8/cairocffi-1.5.1.tar.gz: Executing /tmp/named_caches/pex_root/venvs/b9549377f92ee3eff1e9e1fa14bb6cb3d0147571/5fd7049af63e03f347278c89401424cd9731df9a/bin/python -sE /tmp/named_caches/pex_root/venvs/b9549377f92ee3eff1e9e1fa14bb6cb3d0147571/5fd7049af63e03f347278c89401424cd9731df9a/pex -c import sys

import build

if not hasattr(build, 'prepare_metadata_for_build_wheel'):

result = build.prepare_metadata_for_build_wheel(*('/tmp/pants-sandbox-Fusvjh/.tmp/tmpjtfl64d3/build',), **{})
with open('/tmp/pants-sandbox-Fusvjh/.tmp/tmptd9v7we7', "w") as fp:
 failed with 1

Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.
Looks like it is due to the a new version of the package with only this commit: Can you explain why so I can file an issue there?
When upgrading from 2.15 to 2.16.rc0 I am facing this issue even with 1.5.0 of that package
@thousands-plumber-33255 that looks like a bug and a different one at that. I'll try to repro here in the next hour and report back.
👍 1
Ok. I repro. The missing reason is just above the fold in your snip - Pants probably hides it:
Copy code
discovered packages -- ['cairocffi']
running dist_info
creating /tmp/tmpk_oljxf2/build/cairocffi.egg-info
writing /tmp/tmpk_oljxf2/build/cairocffi.egg-info/PKG-INFO
writing dependency_links to /tmp/tmpk_oljxf2/build/cairocffi.egg-info/dependency_links.txt
writing requirements to /tmp/tmpk_oljxf2/build/cairocffi.egg-info/requires.txt
writing top-level names to /tmp/tmpk_oljxf2/build/cairocffi.egg-info/top_level.txt
writing manifest file '/tmp/tmpk_oljxf2/build/cairocffi.egg-info/SOURCES.txt'
reading manifest file '/tmp/tmpk_oljxf2/build/cairocffi.egg-info/SOURCES.txt'
reading manifest template '<|>'
adding license file 'LICENSE'
writing manifest file '/tmp/tmpk_oljxf2/build/cairocffi.egg-info/SOURCES.txt'
creating '/tmp/tmpk_oljxf2/build/cairocffi-1.5.1.dist-info'
error: invalid command 'bdist_wheel'
Could not gather lock metadata for 1 project with source artifacts:
So, that's
invalid command 'bdist_wheel'
and that's because the build system requires omits wheel: I have to read some specs to see if that is a bug on their part or on Pex's part. A short term workaround though is to fork the project and add
to those requirements and change your cairocffi requirement to a vcs requirement on your fork.
I'll report back once more with the result of my reading up on whether Pex should automagically always be supplying wheel as a dep to all PEP-517 builders out of band.
Ok, standards aside, Pip does silently provide wheel out of band; so Pex should too. I have some more reading to do but I'll file an issue and link that here to track this.
Ah, ok - this is a Pex bug. I'm not consulting
when its present before calling `prepare_metadata_for_build_wheel`(
Ok, @thousands-plumber-33255 Pex 2.1.134 is released with the fix. You should be able to fix your Pants setup by adding this to your `pants.toml`:
Copy code
version = "v2.1.134"
known_versions = [
👀 1
Thank you!
So this can be removed once Pants is including this PEX version=
@thousands-plumber-33255 yup. That's any Pants >= 2.16.0rc1 and 2.17.0.dev4
👍 1