https://pantsbuild.org/ logo
Join Slack
Powered by
How can i turn off deprecation warnings for a pex ...
# general
t
How can i turn off deprecation warnings for a pex binary target? I tried this:
Copy code
pex_binary(
        name='deps',
        execution_mode='venv',
        include_requirements=True,
        include_sources=False,
        include_tools=True,
        layout='packed',
        env={"PYTHONWARNINGS": "ignore"},
    )

FROM base AS production-deps
ARG PYTHON_MAJOR_VERSION
COPY django/production-deps.pex /deps.pex
RUN PEX_TOOLS=1 python${PYTHON_MAJOR_VERSION} /deps.pex venv --scope=deps --collisions-ok --compile --rm all /bin/production
But that still gives me all those warnings when I run the pex:
Copy code
/bin/production/lib/python3.12/site-packages/pydantic/_internal/_config.py:323: PydanticDeprecatedSince20: Support for class-based `config` is deprecated, use ConfigDict instead. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at <https://errors.pydantic.dev/2.11/migration/>
  warnings.warn(DEPRECATION_MESSAGE, DeprecationWarning)
I can even see in the /bin/production/pex file that it injects the envs. But why is that ignored at all?
@brief-scientist-13682 idea?
c
Does 
PYTHONWARNINGS=ignore
work as you set it in the Dockerfile or manually?
It is kind of John to hang out in this slack; but this isn't the right place to ping people for help with how Pants wraps another tool.
b
Thanks @curved-manchester-66006 - agreed. That said, why on earth would you suppress warnings inherent to your app, in the app container? Why not set up your warnings filter in your own 
___main___
?
That way - no matter how your app is run, its will do what your app is meant to do.
t
@curved-manchester-66006 I tried that and neither works. @brief-scientist-13682 that was just an example of third party packages I use, which spam my logs. My own app warnings would still apply.
Even setting my own warnings filter does not work, with this entry point script for the pex file:
Copy code
import os
import sys
import warnings


def run_gunicorn() -> None:
    """
    Setup gunicorn and run.
    """
    # If no args were provided, fill them in for convenience.
    if len(sys.argv) == 1:
        sys.argv.extend(['--config', 'python:gunicorn_conf'])
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'django_core.settings')
    from gunicorn.app.wsgiapp import run

    sys.exit(run())


if __name__ == '__main__':
    warnings.simplefilter('ignore')
    run_gunicorn()
b
@thousands-plumber-33255 if that main works outside of the PEX file but fails to work when run in a PEX file, then it's a Pex problem and I'm interested. Is that the case?
t
That setup is quite complex and not sure if i can run it without pants 😮
b
Ok, well I'm going to assume you have a Python problem and not a Pex problem if that 
__main__
edit didn't do it. By the time 
__main__
is executing, Pex is out of the picture. FWIW, in the original env based approach, PEXes are hermetic by default and screen all PYHTON env vars (so PYTHONPATH can't leak into the PEX 
sys.path
). You can cancel that in the 
--venv
case with 
--non-hermetic-venv-scripts
. For example:
Copy code
:; pex --venv -o empty.venv.pex --seed 
/home/jsirois/.cache/pex/venvs/3/e6ed52029a84b98d42fb954d4853f9d28046fe8b/485b182d3b10432d6a5f1f5be4248d540afe6b7b/pex

:; head -1 /home/jsirois/.cache/pex/venvs/3/e6ed52029a84b98d42fb954d4853f9d28046fe8b/485b182d3b10432d6a5f1f5be4248d540afe6b7b/pex
#!/home/jsirois/.cache/pex/venvs/3/s/17835cf0/venv/bin/python3.14 -sE
Versus:
Copy code
:; pex --venv --non-hermetic-venv-scripts -o empty.venv.leaky.pex --seed
/home/jsirois/.cache/pex/venvs/3/cbaea3e73c7497750383af2a14361b0f3f351152/485b182d3b10432d6a5f1f5be4248d540afe6b7b/pex

:; head -1 /home/jsirois/.cache/pex/venvs/3/cbaea3e73c7497750383af2a14361b0f3f351152/485b182d3b10432d6a5f1f5be4248d540afe6b7b/pex
#!/home/jsirois/.cache/pex/venvs/3/s/0125a3f7/venv/bin/python3.14
Where 
-E
tells python to ignore `PYTHON*`env vars.
Also - your OP shows you splitting your app into 2 - the pex_binary target is deps only and has no entry point; so, at the very least, you're leaving out relevant details.
From what you did include in the OP though, this line:
Copy code
RUN PEX_TOOLS=1 python${PYTHON_MAJOR_VERSION} /deps.pex venv --scope=deps --collisions-ok --compile --rm all /bin/production
Creates a plain old venv at /bin/production. There is 0 PEX at that point unless you run the 
/bin/production/pex
script. You can always run 
/bin/production/bin/python -m my.main.module
, etc to completely take Pex out of the picture and determine if it's a Pex issue or a Python issue.
👀 1
So @thousands-plumber-33255 no matter how complex your app is, playing around like that in the final venv should be able to narrow down Pex issue or Python issue. Let me know if that messing around provides definitive proof it's a Pex issue and I'll investigate further.
7 Views
Open in Slack
PreviousNext
Powered by