Disable easy_install command and remove sandbox functionality.

[jaraco]

Ref #917

[jaraco]

I've filed pbr-2107732 to track an integration issue with the proposed work.

[rgommers]

@jaraco this PR's title didn't set off alarm bells for me, but I glanced at the linked pbr issue and there you say:

I've worked out that the develop command can be all-but-removed, and all the 'editable install' tests still pass.

Disabling python setup.py develop will have a much larger blast radius than only removing the easy_install executable I'd think? E.g., I know PyTorch uses it still - I'd expect a lot of projects to still rely on it.

Are you trying to remove both easy_install and the develop command at once here?

[jaraco]

Are you trying to remove both easy_install and the develop command at once here?

I appreciate the concern. Thanks for reaching out.

I'm trying mainly to remove easy_install but develop depends on easy_install, so it becomes all-but-necessary to remove develop.

I was thinking that because setup.py develop is deprecated and superseded by a replacement for years and because it's not an integration concern (i.e. invoked implicitly as part of another process) but a user concern, use-cases that depend on it could be readily worked around by pinning to an older Setuptools. Should I think about it differently?

[jaraco]

In #4955, I'm considering a different tack for decoupling develop from easy_install. I've also created debt/remove-develop to track removing the develop command separately from the effort of disabling easy_install.

[rgommers]

I was thinking that because setup.py develop is deprecated and superseded by a replacement for years and because it's not an integration concern (i.e. invoked implicitly as part of another process) but a user concern, use-cases that depend on it could be readily worked around by pinning to an older Setuptools. Should I think about it differently?

The problem with that deprecation of all of direct python setup.py xxx is that it's so large that people have been ignoring it, and also that there aren't ready-made replacements for everything.

It's possible to say "pin to and older version" and at some point that's going to be needed. But it'll still be disruptive. What I would recommend is decouple easy_install and develop removals (as you're trying in gh-4955), and to announce a timeline for the develop removal that's say 6 months into the future. That gives people a concrete deadline and a reason to do the work, and will limit the disruption when the removal happens.

[jaraco]

It's possible to say "pin to and older version" and at some point that's going to be needed. But it'll still be disruptive. What I would recommend is decouple easy_install and develop removals (as you're trying in gh-4955), and to announce a timeline for the develop removal that's say 6 months into the future. That gives people a concrete deadline and a reason to do the work, and will limit the disruption when the removal happens.

Thanks for this feedback. I agree that's a good plan and promises to be a lot less disruptive.

I've continued to pursue #4955, which is reaching stability. I plan to merge that and this change at the same time as this change, even though they could be rolled back independently.

[rgommers]

Thanks @jaraco! I will follow up with PyTorch and check in other projects I'm familiar with for remaining develop usages.

[hroncok]

This change broke setup.py install --prefix=.... See #3143