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).

[nanonyme]

Is https://github.com/pypa/setuptools/issues/2828 a dependency for this?

[RalfJung]

It would be nice to get some guidance for what to do instead of setup.py install (which shows warnings pointing here). According to https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html we should do pip install, but I'm not installing a package from PyPI, I am installing a local package. Trying pip install ./package-folder just gives an error:

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

The warning (and README.venv) is confusing since they talk about system-wide installation, but I want it to just install to ~/.local/lib... passing --user does not make a difference.

This is an incredibly frustrating deprecation since it provides no clear guidance on what to do instead. Two different deprecation messages appear, that link to 2 different URLs, and none of them tells me what to do...

[graingert]

@RalfJung your operating system does not allow installations into ~/.local/lib the message is misleading because it "applies both to system-wide installs (sudo pip install) as well as user home directory installs (pip install --user)"

[RalfJung]

Oh I see, I guess I am double-deprecated then -- with installing into ~/.local in the first place and with using setup.py install. That's unfortunate.

[graingert]

@RalfJung also check the note in the error message you pasted it explains several workarounds, such as using a virtual environment directly or with pipx or bypassing the restriction by forcing the install. I'd recommend you use a virtual environment

[RalfJung]

I was hoping not having to learn 2 new tools and change my entire workflow... oh well. pipx is nice though. :)

Anyway I guess the high-level point is that people that only occasionally use Python and avoided virtual environments so far since having to set them up and switch into them is annoying overhead, the guidance provided by these deprecation messages is just not sufficient.

[cottrell]

Message should say replace with

pip install -e .

Please correct if wrong.

[yasirroni]

Message should say replace with

pip install -e .

Please correct if wrong.

-e option is for development mode (it will create path to the repository instead of creating new folder in site-packages directory). To install it is normal mode just use pip install .