melodic-carpenter-39613
06/24/2022, 11:35 AM--python-no-binary
option appears to be what I want, however when trying to create a pex using the pex_binary
target with a top-level python requirement o365==2.0.19
(which has a binary wheel, but depends on stringcase>=1.2.0
which only provides a tarball) I encounter a `pex.result.ResultError`when running ./pants --python-no-binary="['stringcase']" generate-lockfiles && ./pants package ::
. I am using pants_version = "2.13.0rc3"
but when running with -ldebug
I cannot see any evidence of --no-binary stringcase
being set anywhere (inferred from Pull 14985).
Has the --python-no-binary
option been documented, but not implemented yet? How were people in the community solving the issue of sdists in their pex dependencies prior to this?
FTR the ResultError
traceback looks like the following:
pex.result.ResultError: Failed to resolve compatible artifacts from lock 3rdparty/python/default.lock for 1 target:
1. cp37-cp37m-linux_x86_64:
Failed to resolve all requirements for abbreviated platform cp37-cp37m-linux_x86_64 from 3rdparty/python/default.lock:
Configured with:
build: False
use_wheel: True
Dependency on stringcase not satisfied, 1 incompatible candidate found:
1.) stringcase 1.2 (via: o365==2.0.19 -> stringcase>=1.2.0) does not have any compatible artifacts:
<https://files.pythonhosted.org/packages/f3/1f/1241aa3d66e8dc1612427b17885f5fcd9c9ee3079fc0d28e9a3aeeb36fa3/stringcase-1.2.0.tar.gz>
Note I have also tried setting the following in pants.toml
to no joy:
[python]
no_binary = ["stringcase"]
lockfile_generator = "pex"
...
[subprocess-environment]
env_vars.add = ["PIP_NO_BINARY=stringcase"]
Any help would be hugely appreciated 🙏happy-kitchen-89482
06/24/2022, 4:36 PMno_binary
at all? If stringcase
has no wheels then the sdist should be consumed automatically./pants --python-no-binary="['stringcase']" && ./pants package ::
, looks odd - it's running pants twice, the first one is a no-op, and the second one doesn't set that flagmelodic-carpenter-39613
06/24/2022, 4:39 PM*.tar*
or *.zip
if a wheel is not available on PyPI (which is the default behaviour of pip I believe)3rdparty/default.lock
) and doing a fresh ./pants generate-lockfiles
but the error still occurs when doing the ./pants package
stephappy-kitchen-89482
06/24/2022, 4:48 PM./pants package
command as well?melodic-carpenter-39613
06/24/2022, 4:52 PM./pants --python-no-binary="['stringcase']" package ::
but it didn't seem to have any affect either way... Would it help if I provided a snipped for the pex_binary
within my BUILD
?happy-kitchen-89482
06/24/2022, 4:58 PMmelodic-carpenter-39613
06/24/2022, 5:00 PMBUILD
file for the pex is:
# type: ignore
python_sources(
name="statics",
dependencies=[
"src/python/apps/myapp/templates",
"src/python/apps/myapp/assets",
],
)
dependencies = [
"3rdparty/python:requirements", # python_requirements target pointing to requirements.txt with o365
":statics",
"src/python/libs/mylib:mylib_sources",
"src/python/apps/myapp/myapp:myapp_sources",
]
pex_binary(
name="gunicorn_run",
description="Self-contained Django executable served with gunicorn",
entry_point="gunicorn_run.py",
include_requirements=True,
platforms=["linux-x86_64-cp-3.7.13-m"], # NOTE: previously 3.7.5
dependencies=dependencies,
emit_warnings=True,
restartable=True,
)
file(name="server", source="start-server.sh")
happy-kitchen-89482
06/24/2022, 5:15 PM"3rdparty/python:requirements"
dependency3rdparty/python:o365
hundreds-father-404
06/24/2022, 5:17 PMhappy-kitchen-89482
06/24/2022, 5:17 PMplatforms=["linux-x86_64-cp-3.7.13-m"]
stringcase
, if you're not running on a linux-x86_64-cp-3.7.13-m
platform then you can't build a compatible wheel on your platformmelodic-carpenter-39613
06/24/2022, 5:23 PM[python]
interpreter_constraints = ["==3.7.13"]
3rdparty/python:requirements
dependency and platforms
causes pants to work 🙌
I cannot say how grateful I am as I've been really hitting a brick wall on this! Thanks for all of your help 😀