v2.19.0: No longer finds dependencies #2532
Comments
|
@mtimm I may not need this info, but in case:
|
We have a rather distinct docker and package repo setup with our own repos and hardened images. I will need to distill that down to something generic and recreate the issue there. It shouldn't take too long though. |
|
Here is the distilled Dockerfile: I tested it and it had the same issue with v2.19.0 but not with v2.18.1: |
|
Ok, thanks @mtimm. In the meantime I reproed with a bit thinner setup: FROM almalinux:8.10
RUN dnf install -y \
python38-devel \
python3.11-devel \
gcc \
make \
libffi-devel
RUN python3.11 -mvenv /pex/venv && \
/pex/venv/bin/pip install pex
ENV PATH=/pex/venv/bin:$PATH
RUN mkdir /work
WORKDIR /work
COPY pex_requirements.txt .:; docker build -t pex-issues-2532 .
:; docker run --rm -it pex-issues-2532
[root@95e9eb1ce2cc work]# pex -V
2.19.0
[root@95e9eb1ce2cc work]# cat pex_requirements.txt
bcrypt==4.1.3
boto3==1.34.144
botocore==1.34.144
certifi==2024.7.4
cffi==1.16.0
charset-normalizer==3.3.2
configparser==7.0.0
cryptography==42.0.8
decorator==5.1.1
dnspython==2.6.1
docopt==0.6.2
future==1.0.0
futures==3.0.5
hdfs==2.7.3
hvac==0.11.2
idna==3.7
ipaddress==1.0.23
Jinja2==3.1.4
jmespath==1.0.1
MarkupSafe==2.1.5
mock==5.1.0
netaddr==1.3.0
ntplib==0.4.0
paramiko==3.4.0
psutil==6.0.0
py==1.11.0
pycparser==2.22
pycryptodome==3.20.0
PyNaCl==1.5.0
python-consul==1.1.0
python-dateutil==2.9.0.post0
pyvmomi==8.0.3.0.1
PyYAML==6.0.1
requests==2.32.3
retry==0.9.2
s3transfer==0.10.2
setproctitle==1.3.3
six==1.16.0
tornado==6.4
urllib3==1.26.19
packaging==24.1
[root@95e9eb1ce2cc work]# pex --disable-cache --python=python3.8 --python=python3.11 --platform=manylinux_2_17_x86_64-cp-3.8.13-cp38 --platform=manylinux_2_28_x86_64-cp-3.11.9-cp311 --python-shebang="/usr/bin/env python3" -r pex_requirements.txt -o component_deps.pex
Failed to resolve compatible distributions for 1 target:
1: abbreviated platform cp311-cp311-manylinux_2_28_x86_64 is not compatible with:
PyNaCl 1.5.0 requires cffi>=1.4.1 but 4 incompatible dists were resolved:
cffi-1.16.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
cffi-1.16.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
cffi-1.16.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
cffi-1.16.0-cp311-cp311-linux_x86_64.whl
paramiko 3.4.0 requires pynacl>=1.5 but 4 incompatible dists were resolved:
PyNaCl-1.5.0-cp36-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl
PyNaCl-1.5.0-cp36-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl
PyNaCl-1.5.0-cp36-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl
PyNaCl-1.5.0-cp311-cp311-linux_x86_64.whl
cryptography 42.0.8 requires cffi>=1.12; platform_python_implementation != "PyPy" but 4 incompatible dists were resolved:
cffi-1.16.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
cffi-1.16.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
cffi-1.16.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
cffi-1.16.0-cp311-cp311-linux_x86_64.whl
Jinja2 3.1.4 requires MarkupSafe>=2.0 but 4 incompatible dists were resolved:
MarkupSafe-2.1.5-cp311-cp311-linux_x86_64.whl
MarkupSafe-2.1.5-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
MarkupSafe-2.1.5-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
MarkupSafe-2.1.5-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
[root@95e9eb1ce2cc work]#I think the new failure is actually correct, but that's only pedantically true. Before drilling in on that, what are you gunning for here at a high level? I ask because there are at least 3 odd things about your
I'll wait for those answers before going further 1. The underlying error though is caused by a stricter post-resolve check introduced in 2.19.0 here: https://github.com/pex-tool/pex/pull/2512/files#diff-25a4139647109115bfa1e1ed672557a1031bc4506ba99e40d4054ae60987ec9aR135. That Footnotes
|
|
One aside is you can also add |
|
Another way to get this to work with 2.19.0 (or any version) is to add As above though, everything hinges on your answer to question 1. Namely what are you actually trying to accomplish with the built PEX. Where should it be able to run? |
|
Hi @jsirois, I agree our setup may be a bit odd. Without mudding the waters with too many details, our requirements are that we need this pex file:
Before I go down the complete platform path I wanted to answer your question 1 so you can advise on the best way to accomplish it. Thank you! |
|
Ok, then if you're building on an Almalinux 8 that already matches one of your two deployment environments, just pex3 interpreter inspect --python python3.8 --tags --markers -i2 > centos7-cp38-glibc2_17.complete-platform.jsonNow, back on the PEX build machine you can say pex \
--complete-platform centos7-cp38-glibc2_17.complete-platform.json \
--complete-platform almalinux8-cp311-glibc2_28.complete-platform.json \
... |
|
To give you an idea of the difference between an abbreviated abbreviated
|
|
@jsirois thank you very much. These extra details are super helpful. I think the one point I did not fully think through was that pex3 needs to be run on the target machine to generate the complete platform details, but now that I reflect on it, that totally makes sense. I will give this a try in a bit and close the issue after verifying it works like we want. |
|
So, @mtimm to explain why this worked before with the abbreviated Previously, the PEX build would proceed as follows:
With 2.19.0, Pex eagerly checks the resolved manylinux_2_17 foreign platform wheel matches the abbreviated Footnotes
|
|
Ok, well - hopefully this all makes more sense now. That said, Pex lives by the rule of not breaking people as it has done here! I think it may make sense to skip the new |
|
I like the idea of a warning. This issue would likely give enough info for others who are struggling like I was to come up with a workable solution for this sort of requirement. Thanks again. |
jsirois
added a commit
to jsirois/pex
that referenced
this issue
Sep 16, 2024
The addition of wheel tag compatibility to the resolve chech adding in pex-tool#2512 regressed users of abbreviated `--platform` in some cases by failing PEX builds that would otherwise succeed and, later, actually work at runtime. Keep the spirit of pex-tool#2512 by emitting a detailed warning at build time with remediation steps instead of failing the build outright. Fixes pex-tool#2532
|
Thanks for the quick response @jsirois and taking the time to help fill in my knowledge gaps. I have tested the changes I need to make and it all seems to work as expected with 2.19.0 using complete-platform. Feel free to close this issue when you have the release out. Thanks again! |
|
Ok, the fix for |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We build a pex file using an almalinux 8.10 container with python 3.8 and python 3.11 installed with the command:
pex -v --disable-cache --python=python3.8 --python=python3.11 --platform=manylinux_2_17_x86_64-cp-3.8.13-cp38 --platform=manylinux_2_28_x86_64-cp-3.11.9-cp311 --python-shebang="/usr/bin/env python3" -r pex_requirements.txt -o component_deps.pexThis was functional up until pex v2.19.0.
With version pex v2.19.0 we now get:
I think in previous versions these dependencies were resolved by building them at the time the pex file is being built. It looks like they are being built by v2.19.0 based on debug output if I increase the verbosity. It seems like wheels built as part of the pex build are not being found to resolve the dependencies once they are built. At least that is my best guess.
The pex_requirements.txt we are using is:
The text was updated successfully, but these errors were encountered: