Pip currently relies on setuptools to perform a setup.py develop install of a package for "editable" installs. This invocation of develop has implicit dependencies on other behaviors such as setup_requires and the old egg-info metadata format.

Setuptools should support generation of more modern metadata formats (dist-info) natively such that tools like pip can create editable installs without invoking legacy behavior.

This functionality doesn't necessarily need to be embedded with setuptools.

pkg_resources has some undesirable behaviors that are difficult to disentangle from some of its essential functions. In particular, on import, pkg_resources performs a scan of the path and assembles a working set of packages. This behavior has a high cost in some environments.

Alternatives have emerged for some of the use-cases, including entrypoints, importlib_resources, and importlib_metadata, some of which are included or slated to be included in the stdlib.

Although there were once plans to extract pkg_resources into a separate library, the bootstrapping challenges and possibility of dependency on the implicit behavior on import make that a challenging prospect. Instead, setuptools should work to direct users to these alternative solutions and identify unsupported use-cases and shore up those use-cases in the alternative solutions.

The invention of pip has long been crowned the replacement for the installer behavior in setuptools. Since the release of pip 10, the Python ecosystem has a better model for addressing the build dependencies by supporting PEP 518.

This project wishes to eliminate all dependency on the easy_install behavior (the distutils command, console script) including support for setup_requires.

As discussed in #1688., the approach setuptools would like to take is to eventually use a single declarative format (pyproject.toml) instead of maintaining 2 (pyproject.toml/setup.cfg).

Originally posted by Paul Ganssle in #1688 (comment):

Add pyproject.toml as the one true way to do declarative builds, moving all setuptools configuration over there and deprecating setup.cfg (partially what is discussed in #1160, and if we decide on that option we can move over to that issue).

Originally posted by Jason R. Coombs in #1688 (comment)

One way to ease the transition could be for the setup.cfg code to generate a .toml file and consume then have the pyproject.toml consumer just load both files. That way, a project seeking to transition would only need to do one build, manually merge the two .toml files, and delete setup.cfg.

Relevant tool: ini2toml