[BUG] INFO log level is no longer default for some commands

[cboylan]

setuptools version

60.0.0 and newer

Python version

Python 3.8

OS

OpenSUSE Tumbleweed

Additional environment information

No response

Description

When running certain commands setuptools seems to log at a WARN level and not INFO level which was the previous default. This appears to have changed with the switch from stdlib to local distutils vendoring in 60.0.0. 59.8.0 continues to log at an INFO level as expected. The latest 60.5.4 release continues to log at a WARN level by default. Commands like sdist appear to log at an INFO level though making me suspect that this is limited to distutils commands and not those that setuptools has overridden.

The example I've used below is build_scripts because it is relatively simple but it seems to affect others as well. Calling this out as recent changing to setuptools logging seem to indicate a desire to maintain backward compat with distutils for now and that seems to have broken though I don't understand how/why. Also, pointing this out in case it points to bigger issues in the local vendoring of distutils.

Expected behavior

I expect setuptools to continue logging at INFO level by default.

How to Reproduce

1. Create setup.py with scripts entry.
2. Install setuptools 59.8.0
3. Run setup.py build_scripts --dry-run
4. Install setuptools 60.0.0
5. Run setup.py build_scripts --dry-run
6. Note that there is no log.info() message indicating a mode change would occur.

Note that setting -v on the commands does not change the output. Additionally setting SETUPTOOLS_USE_DISTUTILS=stdlib corrects this on newer setuptools indicating the local vendoring is likely to blame.

Output

$ .tox/py38/bin/pip install -U setuptools==59.8.0
Collecting setuptools==59.8.0
  Using cached setuptools-59.8.0-py3-none-any.whl (952 kB)
Installing collected packages: setuptools
  Attempting uninstall: setuptools
    Found existing installation: setuptools 60.0.0
    Uninstalling setuptools-60.0.0:
      Successfully uninstalled setuptools-60.0.0
Successfully installed setuptools-59.8.0
$ .tox/py38/bin/python3 setup.py build_scripts --dry-run
running build_scripts
creating build/scripts-3.8
warning: build_scripts: foo/bar.py is an empty file (skipping)

changing mode of build/scripts-3.8/bar.py
$ .tox/py38/bin/pip install -U setuptools==60.0.0
Collecting setuptools==60.0.0
  Using cached setuptools-60.0.0-py3-none-any.whl (952 kB)
Installing collected packages: setuptools
  Attempting uninstall: setuptools
    Found existing installation: setuptools 59.8.0
    Uninstalling setuptools-59.8.0:
      Successfully uninstalled setuptools-59.8.0
Successfully installed setuptools-60.0.0
$ .tox/py38/bin/python3 setup.py build_scripts --dry-run
running build_scripts
creating build/scripts-3.8
warning: build_scripts: foo/bar.py is an empty file (skipping)

Code of Conduct

• I agree to follow the PSF Code of Conduct

[dalcinl]

@cboylan I believe this is a duplicate of #3035

[cboylan]

@cboylan I believe this is a duplicate of #3035

I agree this seems to be the case. I'll leave this open as it has a bit of additional info, but won't be bothered if someone closes it. Or feel free to tell me I should close it and I'll do that.

[abravalheri]

Hi @cboylan, thank you very much for reporting this problem.

I believe I found the cause in #3042.

Could you provide a reproduction for this step:

1. Create setup.py with scripts entry.

so I can manually test if the fix I devised also applies to your use case?

(e.g. dummy package repository on GitHub).

[cboylan]

In my case I just did a local modification to a small utility, bindep, that I happened to have on disk. I've pushed that modification up to https://review.opendev.org/c/opendev/bindep/+/825973. It has been so long since I wrote a proper setup.py that it would probably take me far too long to figure out so hopefully this works.

To grab this code yourself you can

git clone https://opendev.org/opendev/bindep
cd bindep 
git fetch https://review.opendev.org/opendev/bindep refs/changes/73/825973/2
git checkout FETCH_HEAD

If this doesn't work I can probably figure out a smaller case but it might be a few days.

[abravalheri]

Thank you very much @cboylan, I think the proposed patch #3042 does fix this problem.
These are the steps I took to confirm:

cd /tmp
git clone https://opendev.org/opendev/bindep
cd bindep 
git fetch https://review.opendev.org/opendev/bindep refs/changes/73/825973/2
git checkout FETCH_HEAD
echo "print('hello world')" > foo/bar.py
virtualenv .venv
.venv/bin/pip install 'setuptools @ git+https://github.com/abravalheri/setuptools@issue-3038'
.venv/bin/python setup.py build_scripts --dry-run

and this is the output:

/tmp/bindep/.venv/lib/python3.8/site-packages/setuptools/dist.py:723: UserWarning: Usage of dash-separated 'author-email' will not be supported in future versions. Please use the underscore name 'author_email' instead
  warnings.warn(
/tmp/bindep/.venv/lib/python3.8/site-packages/setuptools/installer.py:27: SetuptoolsDeprecationWarning: setuptools.installer is deprecated. Requirements should be satisfied by a PEP 517 installer.
  warnings.warn(
/tmp/bindep/.venv/lib/python3.8/site-packages/setuptools/command/easy_install.py:157: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
/tmp/bindep/.venv/lib/python3.8/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
/tmp/bindep/.venv/lib/python3.8/site-packages/setuptools/dist.py:723: UserWarning: Usage of dash-separated 'author-email' will not be supported in future versions. Please use the underscore name 'author_email' instead
  warnings.warn(
running build_scripts
changing mode of build/scripts-3.8/bar.py