This was discussed some time ago in a thread starting here: http://mail.python.org/pipermail/catalog-sig/2011-May/003736.html  I’ll summarize the important parts below.

Currently, upload will only push files that are products of a command run from the same command line, e.g. “sdist upload”.
If you run “sdist”, check the result, and then do “sdist upload”, the second sdist should be exactly the same, unless your setup.py is buggy, you made changes to your files or you have a computer problem.  (I agree that’s a lot of unless).  So for distutils, having to run “sdist upload” is not inefficient, and makes you be explicit about the files you want to push, which is IMO good.

A trick can be used to avoid the second sdist to redo all its work: Fist you run “python setup.py sdist --keep-temp”, then you check the sdist, and to upload you call “python setup.py sdist --dry-run upload”.  I’m not in favor of adding that trick to the doc, as for normal usage, running sdist twice is okay.

As you may not be aware, distutils is under a feature freeze.  To cut a long story short, let’s just say that it’s impossible to gradually improve it without breaking a lot of third-party code, so we only fix bugs and we add features in distutils2, the next gen (included in Python 3.3 and available on PyPI for 2.4-3.2 soon).

I think there are good arguments to improve upload for distutils2, mainly:
- you never know what can go wrong, so you want to upload files you have tested
- PyPI will reject bad files anyway, no sense in being more restrictive on the client side

I propose a new option, say -f/--file, that takes a filename as argument:

  pysetup run upload -f dist/spam-0.2.tar.gz -f dist/spam-0.2.exe

I’d prefer to avoid globs (upload -i 'dist.spam-0.1.*' e.g.) because I want to retain the original design choice of the upload command: the person doing the upload needs to be explicit about what kind of file for what versions and with what Python version to upload.

Does that sounds good?