Thanks! #1 is a great idea. I hadn't thought of that. #2 was previously rejected. #3 was basically what I was trying to avoid, because (in this usage) i'd have to turn everything off by default and then turn things on for CI/testing contexts
On Friday, July 11, 2025 at 2:01:11 PM UTC-4 Michael Merickel wrote: > Some options: > 1. Don’t have pyramid imported when you import your package. Wait until > main() is called. > 2. Set the PYTHONWARNINGS env var in your env prior to the script running. > 3. In your package define an __init__.py that configures warnings prior to > importing anything else. > > Not saying they’re great options but trying to help. > > - Michael > > On Jul 11, 2025, at 11:10, Jonathan Vanasco <[email protected]> wrote: > > This is an annoying issue related to pkg_resources being deprecated ( > https://github.com/Pylons/pyramid/issues/3731); I am wondering if anyone > has figured out a solution for it. > > > > The /scripts with registered entrypoints have executables created that > look like this: > > # -*- coding: utf-8 -*- > import re > import sys > from {{MYAPP}}.scripts.{{SCRIPTNAME}} import main > if __name__ == '__main__': > sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0]) > sys.exit(main()) > > When these scripts are executed, the Python interpreter will first import > {{MYAPP}}which will import Pyramid, which then imports pkg_resources, > which then emits the warning. > > I can't figure out a way to suppress this warning during console script > execution, aside from disabling it in every context. I am fine with this > on the webapp, but this creates noise - and problems - for console scripts > that are registered into cron. > > Disabling warnings in the script does not work, because the > /scripts/{{script}} is imported *after* the topline namespace is imported. > > I don't think there is anything I can do here, but wondered if anyone else > has figured this out. > > The only approach I can think of, is disabling this warning in all > contexts by default, then letting me re-enable it via an environment > variable and having a unit test do coverage for it. I'd rather not do > that, but it may be the only way. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/pylons-discuss/1ad7075b-94dd-4eaf-8def-91779bc156den%40googlegroups.com > > <https://groups.google.com/d/msgid/pylons-discuss/1ad7075b-94dd-4eaf-8def-91779bc156den%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/pylons-discuss/46d5051b-9bbd-4df4-bdbd-e8992b6bb01bn%40googlegroups.com.
