List view
Replace the use of distutils with setuptools-native functionality or alternative approaches.
No due date•2/2 issues closedAs 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 https://github.com/pypa/setuptools/issues/1688#issue-411224984: > 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 https://github.com/pypa/setuptools/issues/1160, and if we decide on that option we can move over to that issue). Originally posted by Jason R. Coombs in https://github.com/pypa/setuptools/issues/1688#issuecomment-471212342 > 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`](https://ini2toml.readthedocs.io/en/latest/readme.html)
No due date•0/1 issues closed- No due date•8/9 issues closed
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](https://pypi.org/project/entrypoints), [importlib_resources](https://pypi.org/project/importlib_resources), and [importlib_metadata](https://pypi.org/project/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.
No due date•2/3 issues closedPip 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.
No due date•1/1 issues closedThe 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](https://www.python.org/dev/peps/pep-0518/). This project wishes to eliminate all dependency on the `easy_install` behavior (the distutils command, console script) including support for `setup_requires`.
No due date•4/4 issues closed