#3310 makes twine --skip-existing option useless

[mayeut]

twine checks for message starting with File already exists:
https://github.com/pypa/twine/blob/bcb73e025102565c395e0bf322faebd7f72e76f7/twine/commands/upload.py#L58-L61
Message has been changed to one starting with The filename or contents already exist in #3310:
https://github.com/pypa/warehouse/blob/969695d030aef8b11d5b052e8731a80746c404c8/warehouse/forklift/legacy.py#L1083-L1094

c.f. pypa/twine#332
c.f. failing deployment: https://travis-ci.org/mayeut/gcovr/builds/360424325

[brainwane]

@sigmavirus24 @jonparrott @di I'm offline much of today, could one of you take a look at this?

Thanks for the report, @mayeut.

[mayeut]

@brainwane, given you're comment in pypa/twine#332 (comment) saying it shall probably be fixed in twine, I guess one thing that could be done is add a comment in warehouse. Maybe something like:
# changing the message might break twine --skip-existing
This will prevent further issues from popping up. At least, there can be some coordination before an issue arises (e.g. release twine with new message support then change the message).

[sigmavirus24]

With my twine hat on, I've always been of the opinion that our current checking around this is fragile and sucks. If Warehouse can provide us with something better that would be fantastic. It seems like Warehouse, however, has traded one plain-text string for another. For this API, I understand returning plain-text/html, but I think if the client says they accept JSON, a JSON payload would be leagues better. Just my 2cents

[di]

Hmm, this is unfortunate. Seems like we should revert the error message change so that this behavior is restored for older Twine clients, and then work on improving the brittleness of this in Twine.