classification
Title: upload command no longer accepts repository by section name
Type: Stage:
Components: Distutils, Distutils2 Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7, 3rd party
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: alexis, eric.araujo, jaraco, tarek, techtonik
Priority: normal Keywords: patch

Created on 2011-03-11 22:31 by jaraco, last changed 2013-11-10 16:28 by jaraco. This issue is now closed.

Files
File name Uploaded Description Edit
test-11473-py32.diff eric.araujo, 2011-09-13 15:20 review
.pypirc jaraco, 2011-09-28 16:09 .pypirc present when error occurred
smime.p7m jaraco, 2012-01-06 17:31
Messages (10)
msg130635 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2011-03-11 22:31
It appears that with Python 3.2 (Windows 64-bit), the distutils upload -r command no longer accepts the repository section name, but instead only attempts to parse it as a URL. This is a regression from Python 2.7.

PS C:\Users\jaraco\projects\hgtools> python -m pdb setup.py sdist upload -r pypi
> c:\users\jaraco\projects\hgtools\setup.py(7)<module>()
-> """
(Pdb) c
running sdist
running egg_info
# lines elided
running upload
Submitting dist\hgtools-1.0b1.zip to pypi
Traceback (most recent call last):
  File "c:\python\lib\pdb.py", line 1556, in main
    pdb._runscript(mainpyfile)
  File "c:\python\lib\pdb.py", line 1437, in _runscript
    self.run(statement)
  File "c:\python\lib\bdb.py", line 392, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "c:\users\jaraco\projects\hgtools\setup.py", line 7, in <module>
    """
  File "c:\python\lib\distutils\core.py", line 149, in setup
    dist.run_commands()
  File "c:\python\lib\distutils\dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "c:\python\lib\distutils\dist.py", line 938, in run_command
    cmd_obj.run()
  File "c:\python\lib\distutils\command\upload.py", line 66, in run
    self.upload_file(command, pyversion, filename)
  File "c:\python\lib\distutils\command\upload.py", line 176, in upload_file
    raise AssertionError("unsupported schema "+schema)
AssertionError: unsupported schema
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> c:\python\lib\distutils\command\upload.py(176)upload_file()
-> raise AssertionError("unsupported schema "+schema)
(Pdb) self.repository
'pypi'
(Pdb) schema
''
(Pdb) q
msg143544 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-09-05 16:15
I started working on a test for this in packaging and it’s worse than I expected: it does not support multiple repositories at all.  The config parser has bogus tests and the upload command has no test for this.  I will work on fixing this in packaging and backport.
msg143975 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-09-13 15:20
This is a strange bug.  I added a test using -r server2, using the already-existing PYPIRC_LONG_PASSWORD string as .pypirc contents.  The test passes.  To make sure changing one test would not affect another one, I created a new .pypirc file, PYPIRC_CUSTOM_SERVER, and then I got to see your bug!  I tried various combinations of keys (realm or not, user or not), changed the markup (: or = as delimiter, spaces or not) but could not easily find the root of the bug.

Can you publish a .pypirc file that works with 2.7 and not with 3.2?  That would be a good starting point.
msg144569 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2011-09-28 16:09
I now seem to be unable to reproduce the issue. I do keep my .pypirc in a revision control system, so I have reasonable confidence that my .pypirc contained the content that I'm attaching now (passwords scrubbed of course).

One possible factor is that my .pypirc is symlinked from ~/.pypirc to config/python/.pypirc and it's conceivable that Python 3.2.0 has some issues with symlink resolution that caused it to not process the .pypirc properly.

I'm going to install Python 3.2.0 and try to reproduce the issue there.
msg144571 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2011-09-28 16:38
Sure enough. I just confirmed that with Python 3.2.0, if .pypirc is symlinked, distutils behaves as if the .pypirc isn't present at all, but if that same .pypirc is copied, it behaves as expected. If one deletes the .pypirc altogether, it produces the same error.

Furthermore, this issue was fixed before the release of 3.2.2 (probably in 3.2.1).

My guess is that with the PYPIRC_CUSTOM_SERVER, it was somehow not being installed or resolved correctly, so the content was irrelevant.

I suggest we mark this bug as resolved (as the primary cause was due to the file not being read at all), but also apply your patch (which has some other good fixes) without the CUSTOM_SERVER, or with a version of the CUSTOM_SERVER that works.
msg150743 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-01-06 16:50
[copy/paste failure in my previous message, please disregard]

> One possible factor is that my .pypirc is symlinked from ~/.pypirc to config/python/.pypirc and
> it's conceivable that Python 3.2.0 has some issues with symlink resolution that caused it to not
> process the .pypirc properly.

Are these Windows symlinks?  Are they supposed to be dereferenced transparently by the OS (i.e. during open) like unix symlinks?

> Sure enough. I just confirmed that with Python 3.2.0, if .pypirc is symlinked, distutils behaves
> as if the .pypirc isn't present at all, but if that same .pypirc is copied, it behaves as
> expected. If one deletes the .pypirc altogether, it produces the same error.

OK.  For distutils2, I think we’ll want better logging/error reporting.  The user should see “no /what/ever/.pypirc found”, not “section not found”.

> I suggest we mark this bug as resolved (as the primary cause was due to the file not being read at
> all), but also apply your patch (which has some other good fixes) without the CUSTOM_SERVER, or
> with a version of the CUSTOM_SERVER that works.

Agreed.  I’ll resume work on that patch to understand why it fails.
msg150753 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2012-01-06 17:31
Windows symlinks, much like Unix symlinks, should dereference naturally when open is called, although there is a bug in later versions of the c runtime calling stat on a symlink. See issue6727 for details.
msg175514 - (view) Author: anatoly techtonik (techtonik) Date: 2012-11-13 18:15
So, if upload command never accepted repository by section name I am +1 for closing this issue (and opening a new one if symlink workaround is required).
msg175517 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-11-13 18:50
If you read the first message again, or the docs, you can see that -r repo-name was indeed supported.
msg202533 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2013-11-10 16:28
Indeed, the issue as reported is invalid.
History
Date User Action Args
2013-11-10 16:28:33jaracosetstatus: open -> closed
resolution: not a bug
messages: + msg202533
2012-11-13 18:50:31eric.araujosettitle: upload command no longer accepts repository by section name -> upload command no longer accepts repository by section name
messages: + msg175517
versions: + Python 3.4
2012-11-13 18:15:48techtoniksetnosy: + techtonik
messages: + msg175514
2012-01-06 17:31:44jaracosetfiles: + smime.p7m

messages: + msg150753
title: upload command no longer accepts repository by section name -> upload command no longer accepts repository by section name
2012-01-06 16:50:31eric.araujosetmessages: + msg150743
2012-01-06 16:49:55eric.araujosetmessages: - msg150736
2012-01-06 16:33:18eric.araujosetmessages: + msg150736
2011-09-28 16:38:38jaracosetmessages: + msg144571
2011-09-28 16:09:45jaracosetfiles: + .pypirc

messages: + msg144569
2011-09-13 15:20:02eric.araujosetfiles: + test-11473-py32.diff
keywords: + patch
messages: + msg143975
2011-09-05 16:15:08eric.araujosetversions: + 3rd party, Python 2.7, Python 3.3
nosy: + alexis

messages: + msg143544

assignee: tarek -> eric.araujo
components: + Distutils2
2011-03-11 22:32:03jaracosetversions: + Python 3.2
2011-03-11 22:31:56jaracocreate