#19807 closed Bug (fixed)
Creating a superuser doesn't work
Reported by: | Florian Sening | Owned by: | Claude Paroz |
---|---|---|---|
Component: | Core (Management commands) | Version: | dev |
Severity: | Release blocker | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When syncdb asks if it should create a superuser it fails right after the password.
TypeError: must be char, not unicode
Attachments (1)
Change History (14)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Component: | Uncategorized → Core (Management commands) |
---|---|
Severity: | Release blocker → Normal |
We have no sufficient information to set the release blocker flag, unless more details are provided.
comment:3 by , 12 years ago
I'm running Django master on Windows 7 with Python 2.7.2 - traceback is as follows:
Traceback (most recent call last): File "C:\Python27\lib\site-packages\django\core\management\base.py", line 240, in run_from_argv self.execute(*args, **options.__dict__) File "C:\Python27\lib\site-packages\django\core\management\base.py", line 283, in execute output = self.handle(*args, **options) File "C:\Python27\lib\site-packages\django\core\management\base.py", line 413, in handle return self.handle_noargs(**options) File "C:\Python27\lib\site-packages\django\core\management\commands\syncdb.py" , line 109, in handle_noargs emit_post_sync_signal(created_models, verbosity, interactive, db) File "C:\Python27\lib\site-packages\django\core\management\sql.py", line 195, in emit_post_sync_signal interactive=interactive, db=db) File "C:\Python27\lib\site-packages\django\dispatch\dispatcher.py", line 182, in send response = receiver(signal=self, sender=sender, **named) File "C:\Python27\lib\site-packages\django\contrib\auth\management\__init__.py ", line 117, in create_superuser call_command("createsuperuser", interactive=True, database=db) File "C:\Python27\lib\site-packages\django\core\management\__init__.py", line 161, in call_command return klass.execute(*args, **defaults) File "C:\Python27\lib\site-packages\django\core\management\base.py", line 283, in execute output = self.handle(*args, **options) File "C:\Python27\lib\site-packages\django\contrib\auth\management\commands\cr eatesuperuser.py", line 125, in handle password2 = getpass.getpass('Password (again): ') File "C:\Python27\lib\getpass.py", line 95, in win_getpass msvcrt.putch(c) TypeError: must be char, not unicode
I guess this is a Windows-only problem. I'll investigate further.
comment:4 by , 12 years ago
Just wanted to note that this seems to be a Windows-only and non-Django problem.
The error occurs if you use unicode_literals in conjunction with a custom prompt for getpass.
from __future__ import unicode_literals import getpass password = getpass.getpass() password2 = getpass.getpass('Password (again): ')
comment:5 by , 12 years ago
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
Django should use force_str on the prompt before calling getpass
.
Marking as a release blocker again since it appears to be related to unicode_literals
, which is a change in 1.5.
comment:6 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
by , 12 years ago
Attachment: | 19807-1.diff added |
---|
follow-up: 9 comment:8 by , 12 years ago
I dug into the issue just a little bit further. The problem is that getpass does not support Unicode yet (because it doesn't use the Unicode methods of msvcrt). While this is clearly a Python bug it got introduced during the transition of Django from Python 2.x to Python 3.x - hence I too consider it a release blocker.
But I'm not sure about the fix. What happens when getpass gets fixed? Will it break again? Will the test fail? I would prefer a fix that makes Unicode available as soon as this gets fixed.
I can't test the patch right now. Anybody else able to test it?
comment:9 by , 12 years ago
Replying to Semmel:
But I'm not sure about the fix. What happens when getpass gets fixed? Will it break again? Will the test fail? I would prefer a fix that makes Unicode available as soon as this gets fixed.
force_str
is converting to bytestring on Python 2, and let the string Unicode on Python 3, so I think we should be safe on this side.
comment:10 by , 12 years ago
Sounds good + the tests run fine. And of course - this fixes the issue. Great work. :)
comment:12 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Could you please tell us:
--traceback
option