Do something more intelligent when the file already exists on pypi about twine HOT 9 CLOSED

There is no way to upload a file over another file on PyPI (as you and I already discussed on #59). I am also almost entirely certain that PyPI does not support using the Range header to upload a file. Currently, files are uploading using a multipart/form-data POST request. This means that even if we wanted to be able to support Range the current upload API doesn't support it.

The other way to fix this is use different version numbers. If you were uploading CoolProp-5.0.0 you could change the version number to CoolProp-5.0.0post1 which indicates that the code/library/tool is functionally the same, but there's a difference in the releases. This new version will be newer than 5.0.0 as far as pip is concerned and will be installed instead of 5.0.0.

There really isn't anyway of "fixing" this for you.

from twine.

But I can't change the version number as the python wrapper is only one of about 15 different languages that we support and the release number has to be the same between all of them to maintain a simple level of sanity.

Why can't twine just skip the file and keep going if the file it is trying to upload is already on the server? The upload returned an error, can't you parse this error and determine it was because the file was already there, and just move to the next file?

A command line option for what to do when the file already exists could also work:

--exists error: throw an error, abort
--exists warning: runtime error, keep going

A similar problem occurs if you lose internet connection halfway through a large upload with many files.

from twine.

Twine can't generally just skip the file because if you ask a CLI program to do something and it can't do it, then it should return a non zero exit code. In particular this would break anyone relying on twine to nicely report errors so they can automate uploads and determine if they succeeded or not.

As far as an --exists flag, I'm on the fence about it. I'm not sure it would be generally useful.

from twine.

But I have already given two (common) use cases where the existing behavior has problems. The connection interruption is a particularly common and annoying one. The --exists would be backwards compatible (--exists error would be the default)

from twine.

Right. I think my problem is that you may (or may not) need to actually verify the the uploaded files were correctly uploaded or not. Depending on when the connection was interrupted you might have a broken file. I'm not strictly opposed to such a flag, I'm just not sure how generally useful it is. Especially since you can do the same thing just by doing: for f in *.whl; do twine upload $f || echo "Failed to upload $f"; done or something similar.

from twine.

I guess you are right, but it seems like

twine upload --exists warning dist/*

is a much cleaner syntax that less-experienced users would be more comfortable with. Also, nicer to use on windows.

from twine.

Except that --exists is an ambiguous option name. --if-exists would be better but still violates the principle of least surprise and introduces another way of uploading files that aren't broken. Sure it allows the user not to think, but I don't believe that we want people to ignore broken uploads (in the event the first attempt was interrupted) and think that it's a valid wheel. They won't be angry with their internet provider, they'll be angry with us because they made assumptions about what --exists does.

from twine.

Not sure if this was closed because it was solved, but maybe important for anyone that stumbles onto this in the future.

In your project directory

Foo
  |_ foo
       |_ __init__.py
       |_ __main__.py
       |_ ...

#Inside __init__.py Update your version
__version__ = "1.0.1"

This is one way of getting around this problem

from twine.

@tisaconundrum2 --skip-existing is a flag that will skip over files that already exist on PyPI.

from twine.