Setuptools: Replace easy_install with pip 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]

https://github.com/pypa/pip/issues/1820#issuecomment-151329572 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.

[fungi]

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.

Auto-generating pyproject.toml seems like a reasonable workaround. There are plenty of reasons someone may not want to include TOML files in their source code, not the least of which would be in protest of the arrogant attitude which led to the creation of the language in the first place as well as the misogynist jerk who designed it. I personally want no TOML files in software I'm developing, as I wouldn't want others to think I endorse its creator or am accepting of his behavior.

[fungi]

the arrogant attitude which led to the creation of the language in the first place as well as the misogynist jerk who designed it

I gather there are some (other than TPR) who were offended by my empassioned rejection of his legacy, and want to make it clear that while I stand steadfastly by the above criticisms, I did not mean them as a slight against anyone who has attempted to salvage his work on TOML or who might themselves rely on it.

[pganssle]

@fungi This is not the right forum for a referendum on the question of whether or not to use TOML files, nor to discuss the character of its creator. Please keep it on topic.

[fungi]

@fungi This is not the right forum for a referendum on the question of whether or not to use TOML files, nor to discuss the character of its creator. Please keep it on topic.

Yes, sorry, I was attempting to apologize for verging off topic. My point was that auto-generating pyproject.toml should not be indicated as an anti-pattern. The choice to use TOML was a politically-charged one, and there are legitimate reasons, even non-technical reasons, why projects might choose to not carry TOML files and instead seek alternative mechanisms to comply with the PEP.

[benoit-pierre]

See #1830.

[pradyunsg]

Do we know what the next steps here are?

[jaraco]

At this point it seems safe to me that setuptools should be emitting a UserWarning or SetuptoolsDeprecationWarning when easy_install is used or setup.py install is used except in the usages required by pip. And then in short order (weeks to months) remove that functionality.

[pradyunsg]

If so, setuptools can start emitting a warning on usage of easy_install or setup.py install unconditionally IMO.

pip hides setup.py's output if that command succeeds and shows the output (including stderr IIRC) when it fails. Plus, this would also fit in well with pip's plan of dropping the setup.py install codepath as well (pypa/pip#8102).