Deprecate upload and register commands

[di]

Summary of changes

As discussed in #1381, this PR deprecates the upload and register commands by warning the user not to use these commands.

Pull Request Checklist

• News fragment added in changelog.d. See documentation for details

[pganssle]

I'm not sure I understand why the try/catch here.

Can we do this?

self._deprecation_notice()
self.run_command('egg_info')
orig.register.run(self)

Is it because run_command and register.run generate a bunch of text, and you want the deprecation warning to be printed after this text?

If so, maybe this would be better:

try:
    self.run_command('egg_info')
    orig.register.run(self)
except Exception:
    raise
finally:
    self._deprecation_notice()

[di]

Yeah, exactly. I'll switch this to using finally.

[pganssle]

I'm +1 on this initiative, but I do think it would be nice in the documentation for register and upload if we actually provide the specific 1-to-1 equivalents in addition to just linking to the twine documentation. I often find that it's way easier to move over when I don't have to learn a whole new tool just to figure out how to do the equivalent of what I used to do with the old tool.

Also, ideally this would have tests, though I'm not super familiar with the announce mechanism used here and how easy it would be to test that. Maybe the best thing to do is to use a mock of some sort to make sure that announce is called with some regex matching something like .*[Rr]egister.*deprecated.*twine.* (or matching all three patterns [Rr]egister, [Dd]eprecated, twine).

[di]

I'm +1 on this initiative, but I do think it would be nice in the documentation for register and upload if we actually provide the specific 1-to-1 equivalents in addition to just linking to the twine documentation.

I kinda disagree with this, I don't think it should be setuptools's job to tell folks how to use twine.

[pganssle]

I don't think it needs to block this particular PR if you don't want to do it, but the problem is that it has to be someone's job, so either twine should have a "migrating from setuptools" section or setuptools should have a "migrating to twine" section, and whichever one has it, the other one should link to it.

Yes we can just say, "Go ahead and read the twine documentation", but as a practical matter "If you are trying to do X with setuptools, do Y with twine instead!" will get people switching over much faster than just "Use twine for this instead!"

[pganssle]

I think we can link to this in the setuptools documentation for upload. There doesn't seem to be an anchor target for twine register (which I guess is unnecessary now anyway).

[pganssle]

I think the netlify deployment failure was an intermittent failure. I don't seem to have permissions to restart it, though. Close-and-reopen didn't seem to work. @ewdurbin Do you own the netlify account associated here? Do you know if you can give me and the other setuptools maintainers permissions on it?

[ewdurbin]

@pganssle @jaraco was invited as an administrator on the project during PyCon sprints. Can you private message me an email address you'd prefer for me to add yourself as well?

[di]

I think it would be reasonable for twine to have a "migrating from setuptools" guide, let's see what the maintainers there think.

[pganssle]

Awesome, LGTM. We can do a later PR to add links to any potential "migrating from setuptools" section in twine.

[di]

@pganssle Since there was a 40.0 release last night, we'll need to tweak this line before releasing. I took a guess at what version this would land in, but seeing as it's a minor change, this should probably be 40.1.