homepage

explained here: http://wiki.python.org/moin/EnhancedPyPI
The patch also adds unit tests for command/register.py and
command/upload.py

I've changed the target version to 2.6+. We can't add new features to
2.5 and earlier.

please could you remove the deprecated patch.diff ? thanks :)

The last patch also fixes the HOME issues under Windows: #1531505,
#1741, #2166 where .pypirc and .pydistutils.cfg were not found. It is
not using os.path.expanduser to simplify the code usage (~\/ is rather
unreadable) (see the get_home() function in util.py)

I have changed the patch so it uses expanduser (took back tiran's
example from #2166)

Random notes on bugday.distutils.patch:
* dist.py: this change should definitely be applied, no matter what 
 happens to the rest of the patch.
* Yay! Lots of tests!
* distutils.pypirc: I'm doubtful of the finalize_options() here;
 looking for '-r' in the args seems like it could get confused 
 if there are packages or other arguments that just happen
 to use that name. It seems like a remote possibility, but still...
* distutils.pypirc: Class name typo in module docstring.
 
* Would the distutils.pypirc module be better named something like
 distutils.config?
* register.py: why use PyPIRCCommand.DEFAULT_REPOSITORY 
 and not register.DEFAULT_REPOSITORY? I guess it's more useful to
 have a single Distutil-wide default repository. No action needed.

* I like factoring out the .pypirc code into a separate class.
* Overall I think the patch is acceptable. We'd need to decide whether
 the new .pypirc is considered suitable -- I don't remember the reaction
 to it on the distutils-sig or catalog-sig -- but this patch seems
 like a decent implementation of the new format.

for the -r option, is has to be catched by both register and upload when
the command is called like this :
 $ python setup.py register sdist upload -r my-pypi
without the args lookup, register will get an empty value for -r. 
This option seems to me quite global to distutils.

I have changed the code: the pypirc module is now called config.

patch with more tests and explanations...
for the -r option, the standard call without the change would be:
$ python setup.py register -r pypi sdist upload -r pypi
which is very redundant. That's why config.py looks into args.
To avoid collisions, the right thing to do imho would be to have a
"shared_options" dict in the command classes to allow a given command
to get some options from another.
For instance, in the register command, in pseudo-code:
class register:
 shared_options = {'upload': ['repository']} 
and in the upload one:
class upload:
 shared_options = {'register': ['repository']} 
If register and upload are both present in the command line, then the
option is made available to both commands.
For instance, this two lines would provide the repository to the two
commands:
$ python setup.py register -r pypi sdist upload
$ python setup.py register sdist upload -r pypi (preferred way)
But this will be a patch proposition on its own.

making the contracted repository name work with verify_metadata and
list_classifiers

Is the only purpose of the '-r' in sys.argv code to 
avoid having to specify arguments multiple times when you're doing 
multiple commands on a line? Perhaps it would be acceptable to then 
just drop that bit of code completely; having to specify 'register -r 
pypi upload -r pypi' isn't the worst thing in the world, and it avoids 
worrying about oddball corner cases like 'setup.py newcommand -r 
something-different upload -r pypi'.
So, I'd suggest just taking that code out, and then committing the 
patch.

yes that was just for conveniency, so I guess it can be removed

Committed to trunk as r62998; thank you very much for the patch!

Brett backed out my commit in r63002 because I forgot to include the
distutils.config module. Re-committed in r63014 and r63060.

Thanks for the integration work !
I was wondering: since it superseeds two bugs (issue1741, issue2166)
that where marked to be backported in 2.5.x, should I write 2.5 specific 
patches for those particular fixes ? (windows paths related issues)

This patch has broken test_distutils, which now reports
test_distutils
test test_distutils produced unexpected output:
**********************************************************************
Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc
Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc
Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc
Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc
Using PyPI login from /home/martin/work/py2.6/Lib/distutils/tests/.pypirc
**********************************************************************

This is because the code uses a print statement when opening the .pypirc
file. This was already the case before this patch, but the code was not
covered by tests. (see in previous revision)
The test is not broken, it just ouputs to stdin. 
I would suggest closing this issue and opening a new one entitled:
"distutils should used the logging module to produce output" maybe ?

> This is because the code uses a print statement when opening the .pypirc
> file. This was already the case before this patch, but the code was not
> covered by tests. (see in previous revision)
> 
> The test is not broken, it just ouputs to stdin. 
> 
> I would suggest closing this issue and opening a new one entitled:
> "distutils should used the logging module to produce output" maybe ?
The test *is* (or was) broken - regrtest reported it as a failure.
It effectively, actually, caused a failure of the buildbot slaves.
In any case, I have now replaced the print with self.announce, in
r63575.

Right, Thanks!