pypa / setuptools

Official project repository for the Setuptools build system
https://pypi.org/project/setuptools/
MIT License
2.49k stars 1.19k forks source link

[BUG] local distutils change behavior of standard old distutils.core setup.py scripts to use easy_install #3143

Open hroncok opened 2 years ago

hroncok commented 2 years ago

setuptools version

60.9.3

Python version

3.10.2

OS

Fedora Linux 35

Additional environment information

This is only happening with SETUPTOOLS_USE_DISTUTILS=local i.e. the default.

Description

With a very simple setup.py script like this:

from distutils.core import setup

setup(name='wtf', version='1')

When I install the package with python setup.py install --prefix <custom_value> the installation warns me about missing support for .pth files, installation target not being on PYTHONPATH, easy_install deprecation and more. At the end, it produces an egg.

(__venv__) [wtf]$ python setup.py install --prefix .../fake_prefix
running install
.../__venv__/lib64/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
.../__venv__/lib64/python3.10/site-packages/setuptools/command/easy_install.py:160: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
Checking .pth file support in .../fake_prefix/lib/python3.10/site-packages/
.../__venv__/bin/python -E -c pass
TEST FAILED: .../fake_prefix/lib/python3.10/site-packages/ does NOT support .pth files
bad install directory or PYTHONPATH

You are attempting to install a package to a directory that is not
on PYTHONPATH and which Python does not read ".pth" files from.  The
installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

    .../fake_prefix/lib/python3.10/site-packages/

and your PYTHONPATH environment variable currently contains:

    ''

Here are some of your options for correcting the problem:

* You can choose a different installation directory, i.e., one that is
  on PYTHONPATH or supports .pth files

* You can add the installation directory to the PYTHONPATH environment
  variable.  (It must then also be on PYTHONPATH whenever you run
  Python and want to use the package(s) you are installing.)

* You can set up the installation directory to support ".pth" files by
  using one of the approaches described here:

  https://setuptools.pypa.io/en/latest/deprecated/easy_install.html#custom-installation-locations

Please make the appropriate changes for your system and try again.
running bdist_egg
running egg_info
writing wtf.egg-info/PKG-INFO
writing dependency_links to wtf.egg-info/dependency_links.txt
writing top-level names to wtf.egg-info/top_level.txt
reading manifest file 'wtf.egg-info/SOURCES.txt'
writing manifest file 'wtf.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
creating build/bdist.linux-x86_64/egg
copying build/lib/wtf.py -> build/bdist.linux-x86_64/egg
byte-compiling build/bdist.linux-x86_64/egg/wtf.py to wtf.cpython-310.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
copying wtf.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying wtf.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying wtf.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying wtf.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
creating 'dist/wtf-1-py3.10.egg' and adding 'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing wtf-1-py3.10.egg
Copying wtf-1-py3.10.egg to .../fake_prefix/lib/python3.10/site-packages

Installed .../fake_prefix/lib/python3.10/site-packages/wtf-1-py3.10.egg
Processing dependencies for wtf==1
Finished processing dependencies for wtf==1

(__venv__) [wtf]$ ls -1 fake_prefix/lib/python3.10/site-packages/
wtf-1-py3.10.egg

This diverges from the expected behavior:

Expected behavior

The following happens with SETUPTOOLS_USE_DISTUTILS=stdlib:

(__venv__) [wtf]$ python setup.py install --prefix .../fake_prefix/
 .../setup.py:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  from distutils.core import setup
running install
running build
running install_egg_info
Creating .../fake_prefix//lib/python3.10/site-packages/
Writing .../fake_prefix//lib/python3.10/site-packages/wtf-1-py3.10.egg-info

(__venv__) [wtf]$ ls -1 fake_prefix/lib/python3.10/site-packages/
wtf-1-py3.10.egg-info

When the package actually has Python files in it, they are installed directly to site-packages instead of an egg.

This in fact replaces a deprecated tool (stdlib distutils) with another deprecated tool (easy_isntall), however in my opinion, the intention of the original code should be preserved. This creates unexpected results in Fedora, where packages that are wrapped in cmake end up installing different files then they epxected.

How to Reproduce

See above.

Output

See above.

hroncok commented 1 year ago

With pip about to deprecate eggs, I would really appreciate it if this behavior (causing eggs to be created for projects that have not created eggs with old distutils) could be fixed.