Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert "drop easy_install script and associated documentation" #1909

Merged
merged 2 commits into from Nov 23, 2019

Conversation

@benoit-pierre
Copy link
Member

benoit-pierre commented Nov 17, 2019

This reverts commit 6e1838a.

This reverts commit 6e1838a.
@benoit-pierre

This comment has been minimized.

Copy link
Member Author

benoit-pierre commented Nov 17, 2019

Also added changelog entries for this and #1830.

@jaraco

This comment has been minimized.

Copy link
Member

jaraco commented Nov 23, 2019

Thanks @benoit-pierre for putting this together. I wonder if we can avoid re-adding this functionality by instead moving it to another package (called easy_install), and having setuptools depend on that package. That decoupling would make it obvious what is deprecated and provide a path to backward compatibility (those requiring/expecting this functionality could retain it by installing easy_install separately).

My main reluctance for doing this is that by adding a dependency, that dependency becomes non-optional (pkg_resources will expect the easy_install package to be present and crash if it's not).

Let me put together a draft.

@pganssle

This comment has been minimized.

Copy link
Member

pganssle commented Nov 23, 2019

@jaraco I think that might overly complicate things. Even in the now-reverted change, all the old functionality was preserved, we just had removed one of the public interfaces. We can just add a new wrapper script that warns that it's deprecated and in say 1 year replace it with one that actually raises an exception, same way we've done for upload and register .

I think there will be very little ongoing support burden to ship a script that just raises an exception, so we should probably just do the lowest-effort thing that gets us to that endpoint without introducing any footguns for end users.

@jaraco

This comment has been minimized.

Copy link
Member

jaraco commented Nov 23, 2019

You make a good argument. I think I agree.

I did throw together the easy_install package. All it needs is a tag to cut a release, but I'll refrain from doing that if we're not going to use it.

@jaraco

This comment has been minimized.

Copy link
Member

jaraco commented Nov 23, 2019

In #1913, I drafted my concept, but right away it reveals issues (with bootstrapping), at least one of the foot guns. Let's proceed with this approach for now.

@jaraco jaraco merged commit e44d9bc into pypa:master Nov 23, 2019
4 of 6 checks passed
4 of 6 checks passed
codecov/patch 78.37% of diff hit (target 84.99%)
Details
codecov/project 84.97% (-0.03%) compared to e31c9f0
Details
Summary 1 potential rule
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
deploy/netlify Deploy preview ready!
Details
@benoit-pierre benoit-pierre deleted the benoit-pierre:resurrect_easy_install_script branch Nov 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.