Remove easy_install

[jaraco]

There are many open issues with Setuptools that stem from the differences between easy_install and pip install. Now that #250 is complete and there exists a mechanism by which pip install can largely satisfy the use cases currently filled by easy_install. Perhaps at some point I will link to or enumerate the issues that would be addressed by such a replacement but not right now.

In the replacement, I imagine the following:

Invocations of easy_install whether from a command-line entry point or an implicit invocation as part of a setup.py install will instead shell out to pip to perform the equivalent operation. Some options may become unavailable while others will be translated to their pip equivalent.

One big open question is whether installs should still be done as eggs (using the deprecated pip install --egg) or if it should rely on pip's use of wheel. I'm leaning toward the latter.

There are probably other open issues that I haven't yet considered.

[graingert]

probably worth just deprecating easy_install and adding a header from the docs that points to pip

[jaraco]

It's not so simple. Easy-install is used by tests requires and setup requires, which has not replacement. Perhaps it makes sense to only replace those functions.

[ghost]

If I'm not mistaken, running pip install while pip is already running can cause problems. The only way that this is going to work is if pip understands setup_requires or setuptools does some sort of runtime hack/monkeypatch on pip.

[ghost]

See pypa/pip#2745 and pypa/pip#2361.

[graingert]

Tests requires should be deprecated in favour of tox

[jaraco]

If I'm not mistaken, running pip install while pip is already running can cause problems. The only way that this is going to work is if pip understands setup_requires or setuptools does some sort of runtime hack/monkeypatch on pip.

I don't think these issues are relevant. In the case where pip is invoking setup.py to build a package from source and that package has setup_requires dependencies, those dependencies would still be "installed", but to a temporary location (perhaps as eggs to ./.eggs as they are now), meaning they would still be isolated from the target environment via subprocesses and temporary directories, so I would expect not to encounter those issues.

[dstufft]

FWIW longer term PEP 518 is the solution to setup_requires.

[graingert]

maybe for now, just a docs header saying, "hey unless you know what you're doing: don't use easy_install, you probably want pip instead"

[marscher]

pypa/pip#1820 (comment) gives a reference on why recursive pip calls are not a good solution. I think this should be handled by setuptools, because setup_requires is a setuptools feature, which pip is currently unaware of.

PEP 518 is only a specification of the actual build time dependencies, but not an attempt to solve the installation problem:

This PEP covers step 2. It is fully expected that a future PEP will cover step 3, including how to have the build system dynamically specify more dependencies that the build system requires to perform its job. The purpose of this PEP though, is to specify the minimal set of requirements for the build system to simply begin execution.

So this is still unsolved, isn't it?

People tend not to use setup_requires, because easy_install does not use wheel and people have to compile eg. hard to build projects like scipy. So one should definitely prefer a wheel supporting mechanism.

[methane]

How about remove easy_install command but keep python -m easy_install for setup_requires for a while?

[ghost]

@jaraco what do you think about autogenerating pyproject.toml for source distributions?

[jaraco]

Sorry for the late follow-up.

@jaraco what do you think about autogenerating pyproject.toml for source distributions?

I think I'd rather users be incentivized to provide the declaration in the preferred location. I'd support a warning, though.

[jaraco]

This issue continues to be an issue if only because not every invocation of setup.py goes through a PEP 518 runner. For example, tox invokes setup.py --name to get the name of a package - that triggers setup_requires/easy_install. Package managers run setup.py --description or setup.py --version to get metadata. Other distutils commands still exist and are certainly in use in the wild. Perhaps we can eliminate the reliance on setup.py invocations entirely, though that prospect seems daunting.