createsuperuser fails if Python can't detect default locale

[Preston Timmons]

Changeset r16182 introduced a get_system_username() function to the createsuperuser command.

This includes the lines:

try: 
    return getpass.getuser().decode(locale.getdefaultlocale()[1]) 
except (ImportError, KeyError, UnicodeDecodeError): 

If Python can't detect the default system locale, local.getdefaultlocale returns (None, None). This causes decode to raise:

TypeError: decode() argument 1 must be string, not None

[Preston Timmons]

Patch to call decode only if default locale is found.

[Aymeric Augustin]

This requires a test, which could be written like this:

locale.getdefaultlocale, old_getdefaultlocale = lambda: (None, None), locale.getdefaultlocale
try:
    # test here
finally:
    locale.getdefaultlocale = old_getdefaultlocale

[Will Hardy]

Added unit test for this fix

[Chris Wesseling]

I think mocking both locale.getdefaultlocale and getpass is one mock to many.
This boils down to testing wether if statements work in python.
I'll attach a patch that also fixes the case of an unknown locale, that someone experienced today setting up his environment...

Though, I don't know whether this last case should be fixed, I suspect it only happens on misconfigured boxes.
But it does fit the title of the ticket.

Someone should check if these test should be skipped on non *nix environments.

[Chris Wesseling]

Just for the record... ​http://pastebin.com/fD4f8uVs contains the traceback of the usecase that happened to someone when having an incomplete or unknown locale.

It's on pastebin, so sprinters review this today! ;-)
In short, the issues are:

• The discription of this ticket, describes the solution, not the problem. I'd like to see a usecase, before the solution goes in.
• the usecase I introduced happened to someone at the sprints, but I'm not sure that it should be fixed; sometimes a traceback, google, fix your box is more helpful than a tool hiding a configuration problem on your box. (o perhaps that extra case shouldn't go in.
• If we decide this should go in. It should be tested on different platforms and perhaps the tests should be skipped on a couple of them. (Anyone up for ​testing this on the Nintendo DS of their kid ;-)

[Chris Wesseling]

mock getpass wasn't cleanup up

[Chris Wesseling]

Remco, you we're right about the mock getpass...

Fixed it in the new patch. All 3 points of my previous post still stand.

[niels_bom]

In reaction to point 2 offered by charstring:
If there's a enviroment configuration problem I'd say it's more friendly to give that notice "We could not find a correct locale setting, please check whether your locale settings are configured correctly" without failing, I know it stumped me. Also: does a weird setting of locale actually cause any problems further down the road?

[Chris Wesseling]

Replying to niels_bom:

In reaction to point 2 offered by charstring:
If there's a enviroment configuration problem I'd say it's more friendly to give that notice "We could not find a correct locale setting, please check whether your locale settings are configured correctly" without failing, I know it stumped me. Also: does a weird setting of locale actually cause any problems further down the road?

Fair enough. So the point would be. Should we fallback silently and try to do the intended thing (quirksmode ;-)) or should we point out the problem in an error, because we might think to be able to interpret the intention, but the user could run into problems in the future.

I agree it's best we point out the problem nicely to have the user fix his environment and save him or her from future trouble.

Any suggestion on the phrasing of the error? Something along the style-guidelines of django errors. Do these exist?

[Karen Tracey]

#17022 reported this again and noted a specific OS where it happens.

[Karen Tracey]

#17185 reported this again.

[Niels Poppe]

I’ve posted #17185 — this is indeed happening when starting any session from an OSX terminal session, even on OS X 10.7.2.

However, having LANG unset, or set to a value a target host OS does not recognize should not be a requirement for running django — just check for a None encoding return and either give up (return an empty username) or try decode it (as ascii or UTF-8) and failing that, return empty.

This simple patch does just that. Please consider a simple fix to a simple problem.

Thanks.

[Niels Poppe]

Replying to charstring:

Replying to niels_bom:

In reaction to point 2 offered by charstring:
If there's a enviroment configuration problem I'd say it's more friendly to give that notice "We could not find a correct locale setting, please check whether your locale settings are configured correctly” …

Fair enough. So the point would be. Should we fallback silently and try to do the intended thing (quirksmode ;-)) or should we point out the problem in an error …

I agree it's best we point out the problem nicely to have the user fix his environment and save him or her from future trouble.

I disagree. It is no error to have no LANG defined in a terminal session. It is documented that locale.getdefaultlocale() can return (None, None).

It is a bug to pass it to decode() without checking. Possible friendly solution would be to say “we can’t work out your terminal character encoding, please enter your username”, but if it happens to be an ascii string that’s a bit silly, isn’t it?

Please default to ‘ascii’ or ‘UTF-8’ and handle UnicodeDecodeError as already implemented.

[Chris Wesseling]

Replying to nlsp:

Replying to charstring:

Replying to niels_bom:

In reaction to point 2 offered by charstring:
If there's a enviroment configuration problem I'd say it's more friendly to give that notice "We could not find a correct locale setting, please check whether your locale settings are configured correctly” …

Fair enough. So the point would be. Should we fallback silently and try to do the intended thing (quirksmode ;-)) or should we point out the problem in an error …

I agree it's best we point out the problem nicely to have the user fix his environment and save him or her from future trouble.

I disagree. It is no error to have no LANG defined in a terminal session. It is documented that locale.getdefaultlocale() can return (None, None).

True. But shouldn't getdefaultlocale return the C/POSIX locale in that case?
I tend to trust the Python core devs on checking this; if they can't figure out the default locale, who am I to assume I can do better?
If getdefaultlocale is broken, fix it in Python.

It is a bug to pass it to decode() without checking. Possible friendly solution would be to say “we can’t work out your terminal character encoding, please enter your username”, but if it happens to be an ascii string that’s a bit silly, isn’t it?

Perhaps. But we shouldn't be fixing problems at either the Python or the OS level.

Please default to ‘ascii’ or ‘UTF-8’ and handle UnicodeDecodeError as already implemented.

(None, None) means "Python can't figure out what the locale should be." I don't think I can do a better job. But feel free to use the testcase setup from my patch to complete your patch. This bickering about how to construct a proposed value the user can correct is pointless, but I find the lack of tests disturbing. ;-)

About the simplicity of the patch: This is hard to test. So the main code may be simple. The testcode, surely isn't. I think that tells us we're trying to fix a very low level problem.

[chrish@…]

This old bug report says that getdefaultlocale() shouldn't be used in new code; use getpreferredencoding() instead.

locale.getpreferredencoding() returns "US-ASCII" on my OS X laptop.

[chrish@…]

Replying to chrish@…:

This old bug report says that getdefaultlocale() shouldn't be used in new code; use getpreferredencoding() instead.

locale.getpreferredencoding() returns "US-ASCII" on my OS X laptop.

Sorry, left out the URL: ​http://bugs.python.org/issue504219#msg8781

[thomaslockhart1976@…]

Any progress on this? chrish seems to have a solution. I see the problem on OSX Lion and I see blog reports that it has been seen on Ubuntu. Seems ripe for fixing...

[dkdndes@…]

I have echo $LANG with de_DE.UTF-8 and still get the problem. What would I need to change as a user (re your statement above - should we let the user fix the environment and prevent him from future problems)? Config: Lion 10.7.2 and python 2.7

[anonymous]

Replying to dkdndes@…:

I have echo $LANG with de_DE.UTF-8 and still get the problem. What would I need to change as a user (re your statement above - should we let the user fix the environment and prevent him from future problems)? Config: Lion 10.7.2, python 2.7., Django 1.4c2

Due to this error syncdb does not work properly with sqlite3 or mysql. I dont experience this problem with version 1.3.1.

[dkdndes@…]

Replying to anonymous:

Replying to dkdndes@…:

I have echo $LANG with de_DE.UTF-8 and still get the problem. What would I need to change as a user (re your statement above - should we let the user fix the environment and prevent him from future problems)? Config: Lion 10.7.2, python 2.7., Django 1.4c2

Due to this error syncdb does not work properly with sqlite3 or mysql. I dont experience this problem with version 1.3.1.

de_DE.UTF-8 will not be recognised - if you change locale to UTF-8 it works in

def get_system_username(): 
    return getpass.getuser().decode(locale.getdefaultlocale()[1])

Hope the information helps to close the issue.

[anonymous]

Replying to thomaslockhart1976@…:

Any progress on this? chrish seems to have a solution. I see the problem on OSX Lion and I see blog reports that it has been seen on Ubuntu. Seems ripe for fixing...

I've git the same problem under Django 1.4 and MacOS. Worked fine with Django 1.3 until yesterday. Would appreciate a bug fix or at least an idea for a work-around. Thanks.

[anonymous]

I have the same problem, since updating to 1.4

[harm]

This seems to be a regression in django 1.4

django 1.3.1 working ok
django 1.4

  File "/home/hnw/releases/dev/hnw/virtualenv/lib/python2.6/site-packages/django/contrib/auth/management/__init__.py", line 85, in get_system_username
    return getpass.getuser().decode(locale.getdefaultlocale()[1])
TypeError: decode() argument 1 must be string, not None

[anonymous]

I confirm this for django 1.4.
Mac OS X 1.7.3

[anonymous]

It helps running

$ export LANG="en_US.UTF-8"

[anonymous]

Assigned to: Nobody. Looks like it's not going to get fixed anytime soon... :( I hate having to maintain my own.

[Ramiro Morales]

Replying to anonymous:

Assigned to: Nobody. Looks like it's not going to get fixed anytime soon... :( I hate having to maintain my own.

Wait, There is a way to spare you that feeling: Do you have a fix? Are you proud of it? Then why don't you add test and documentation and contribute it here as a patch? That would be w win for everybody.

One suggestion: Try to use your real name and not log in as an anonymous so if the fix gets committed we can give you proper credit. In general, we value that every interaction with this ticketing system be made by people using their real name.

[anonymous]

Just to comment: I just ran into this. (clean, django 1.4, debian) THANKFULLY Googling the error led me here, but jeez - I had no IDEA where to look to fix something like this. Initial syncdb blew up, then I tried manually creating a superuser. This is ugly.

Running export LANG="en_US.UTF-8" on the shell before python manage.py createsuperuser *did* fix it for me.

Sorry I'm not submitting tests/patches, but wanted to add to confirmations that this exists, and crops up.

[anonymous]

In OSX Lion using Django 1.4 I had the same error.

I fixed it by editing ~.profile and adding export LANG="en_US.UTF-8"

Then restart your terminal.

[anonymous]

If you have LC_ALL in your environment you may need to run:

export LC_ALL="en_US.UTF-8"

in your shell as well.
At least that worked for me and just doing:

export LANG="en_US.UTF-8"

didn't work.

$ export LC_ALL="en_US.UTF-8" ;python -c 'import locale ; print locale.getdefaultlocale()'
('en_US', 'UTF-8')
$ 

Seems getdefaultlocale looks for many environment variables, in order, and use the first one it finds.

[mrab54@…]

Ran into this on FreeBSD 8.2.

Workaround:

$ echo 'setenv LANG en_US.UTF-8' >> ~/.cshrc

I don't see why this is required. Doesn't Django default to UTF-8? Or default to something?

[Niels Poppe]

Replying to mrab54@…:

Ran into this on FreeBSD 8.2.

Workaround:

[ platform specific shell commands ]

I don't see why this is required. Doesn't Django default to UTF-8? Or default to something?

The whole point is that getting the “username” will never be solved in a platform independent way.

Discussion about whether or not boxes are “misconfigured” when this happens are pointless. In my view is an error making Django depend on this.

One fix is to not try default to a username, another fix is to be more flexible in recovering from possible decoding errors.

Both are better than doing nothing. Or doing what is currently done: starting up a debate on how a ticket should be phrased and then doing nothing again.

Good luck!

[Chris Lawlor <lawlor.chris@…>]

The question of whether or not to assume a default locale should perhaps be moved to a different ticket, or discussed on the developers mailing list. The problem at hand is that not checking for a return value of None when calling locale.getdefaultlocale() is a bug in Django code, and causes createsuperuser to blow up unexpectedly.

I think we can all agree that syncdb could fail more gracefully in this situation. I'm +1 on at least providing a helpful error message to the user which suggests setting one of 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', or 'LANG', though I'm not sure what the implication of returning an empty string for a username is, as in willhardy's patch.

[bill@…]

Hey, I'm a Django newbie, so my judgement may not be sound. But I want to offer an opinion (or two...)

There are valid secondary questions about Django behavior and Python behavior regarding the default locale values. The primary question (to me) is this: There is a bug in Django, because the Django code does not check the validity of the expression it passes into decode(). What is the best way to fix it?

I suggest making a one-token change as follows. Add TypeError to the kinds of exceptions that are caught and handled at this point in the code:

  NEW  line 86:        except (TypeError, ImportError, KeyError, UnicodeDecodeError):

  PRESENT line 86:     except ( ImportError, KeyError, UnicodeDecodeError):

My thinking is that (1) the code is prepared to receive exceptions at this point, and gracefully recovers from them (see line 91), this is a reasonable workaround for the lack of checking of the argument to decode(), and (3) this fix allows manage.py and the tutorial to run without error.

---

In my opinion, it is crucially important that Django fix this ASAP. I really want to use Django, because people I respect say it is great. But the tutorial is dead in the water without a fix for this. And great code does not have a dead tutorial.

[Tony Becker]

Just check for TypeError and be done with it

[Tony Becker]

I'm running into this bug on OSX 10.7.4 and even though it's easy to fix by setting the environment variable, it's annoying, and would be very off-putting if this was my first go-round with Django.

If the system is not able to get a proper default locale and throws the TypeError, everything thereafter is perfectly satisfied dealing with the empty string as a return value. Patch I submitted ("check_for_type_error.diff") implements Bill's suggestion. It works for me after testing in a virtualenv, and is the simplest fix that could possibly work.

[anonymous]

[code]#env LANG=en_US.UTF-8 /usr/local/bin/python manage.py syncdbcode fix create super user on FreeBSD 9.0

[anonymous]

Replying to anonymous:

#env LANG=en_US.UTF-8 /usr/local/bin/python manage.py syncdb fix create super user on FreeBSD 9.0, fist time syncdb, How to fix ready tis issue ?

[anonymous]

This code, fix create super user on FreeBSD 9.0, fist time syncdb, How to fix ready tis issue ?

#env LANG=en_US.UTF-8 /usr/local/bin/python manage.py syncdb

[anonymous]

I must be ran the follow code, in order to add an superuser ready, after syncdb

server#env LANG=en_US.UTF-8 /usr/local/bin/python manage.py createsuperuser --username=superuser --email=superuser@mydomain

[Leif Denby]

Here's a simple patch. It might be better to just fail silently though as the default username is only presented as a help, and the warning I have added might just be confusing.

--- orig/django/contrib/auth/management/__init__.py	2012-07-26 14:48:31.000000000 +0200
+++ /usr/local/lib/python2.6/site-packages/django/contrib/auth/management/__init__.py	2012-07-26 14:49:39.000000000 +0200
@@ -82,7 +82,14 @@
         username could not be determined.
     """
     try:
-        return getpass.getuser().decode(locale.getdefaultlocale()[1])
+        default_encoding = locale.getdefaultlocale()[1]
+        if default_encoding == None:
+            print ("Warning: The default character encoding could not be "
+                "determined, it will be assumed that your local username "
+                "is encoded using UTF-8 (If you wish to use a different "
+                "please set the LANG environment variable).")
+            default_encoding = "UTF-8"
+        return getpass.getuser().decode(default_encoding)
     except (ImportError, KeyError, UnicodeDecodeError):
         # KeyError will be raised by os.getpwuid() (called by getuser())
         # if there is no corresponding entry in the /etc/passwd file

[anonymous]

With leifdenby's path That's OK tks

Password (again):
Superuser created successfully.
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
server#

[cbarrick]

Why are we using locale.getdefaultlocale()[1] instead of locale.getpreferredencoding() as chrish pointed out? (18)

For me locale.getpreferredencoding() returns a satisfactory encoding when locale.getdefaultlocale() returns (None, None).

>>> os.environ['LANG'] = 'en_US.UTF-8'
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> locale.getpreferredencoding()
'UTF-8'

>>> os.environ['LANG'] = ''
>>> locale.getdefaultlocale()
(None, None)
>>> locale.getpreferredencoding()
'US-ASCII'

​getpreferredencoding does exactly what we want without a dependence on $LANG, so simply changing to that seems like the simplest and best solution.

[Ramiro Morales <cramm0@…>]

In [4c934f3921a59c7b3e088f6472b6f6da40848567]:

Made createsuperuser more robust when getting current OS username.

Under some versions of OS X, failure in getting the default system
locale during the syncdb operation of the auth app were causing hard to
diagnose problems afterwards.

No solution based on getpreferredencoding() was chosen because it has
its own problems with certain combinations of Python and OS X versions
(e.g. ​http://bugs.python.org/issue6202).

Thanks prestonsimmons for the report and prestonsimmons and willhardy
for the initial patch.

Fixes #16017.

[bugs-django@…]

Still an issue:

sandbox@reactor webpymail % rm -r webpymail.db; LC_ALL=C LANG=C PYTHONPATH=..:$PYTHONPATH python manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_admin_log
Creating table mailapp_useridentity
Creating table mailapp_userprofile
Creating table mailapp_folderstoexpand
Creating table mailapp_attachments
Creating table address_book

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Traceback (most recent call last):
  File "manage.py", line 37, in <module>
    execute_manager(settings)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/__init__.py", line 459, in execute_manager
    utility.execute()
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/__init__.py", line 382, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
    output = self.handle(*args, **options)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle
    return self.handle_noargs(**options)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 110, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive, db)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/sql.py", line 189, in emit_post_sync_signal
    interactive=interactive, db=db)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 73, in create_superuser
    call_command("createsuperuser", interactive=True, database=db)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/__init__.py", line 150, in call_command
    return klass.execute(*args, **defaults)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
    output = self.handle(*args, **options)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 70, in handle
    default_username = get_default_username()
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 105, in get_default_username
    default_username = get_system_username()
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 85, in get_system_username
    return getpass.getuser().decode(locale.getdefaultlocale()[1])
TypeError: decode() argument 1 must be string, not None

Note that TypeError is raised, which is not on the list of handled exceptions.

Python 2.7.3

Django==1.4.3

The discription of this ticket, describes the solution, not the problem. I'd like to see a usecase, before the solution goes in.

The problem I see is that django produces an unhandled exception in a default configuration of FreeBSD (which does not set LANG environment variable).

This problem can be split into two sub-problems:

1. Django refuses to work in a default configuration of FreeBSD.

2. When django refuses to work, it does not provide user-friendly information on what needs to be done to make it work.

I disagree. It is no error to have no LANG defined in a terminal session. It is documented that locale.getdefaultlocale() can return (None, None).

It is a bug to pass it to decode() without checking. Possible friendly solution would be to say “we can’t work out your terminal character encoding, please enter your username”, but if it happens to be an ascii string that’s a bit silly, isn’t it?

Please default to ‘ascii’ or ‘UTF-8’ and handle UnicodeDecodeError as already implemented.

Agree with this.

I tend to trust the Python core devs on checking this; if they can't figure out the default locale, who am I to assume I can do better?

If you cannot figure out the default locale, and therefore are unable to determine how to interpret the username obtained by getuser(), why not take the except path and set the initial username to an empty string? Sounds like a better solution than preventing the user from being able to use django applications entirely.

https://code.djangoproject.com/attachment/ticket/16017/check_for_type_error.diff does fix the issue, although it is rather a hack. Instead the return value of getdefaultlocale should be checked before being used.

[bugs-django@…]

1.5.x branch appears to implement setting to empty string on unknown locale.

[ank.bnsl@…]

hi .
Current i am getting the above mentioned error .
Please find logs below :"
ankbansa-MacBookPro:acdb ankbansa$ python manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table resultEntry_testcase
Creating table resultEntry_buildinfo
Creating table resultEntry_result
Creating table django_admin_log

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): y
Please enter either "yes" or "no": yes
Traceback (most recent call last):

File "manage.py", line 10, in <module>

execute_from_command_line(sys.argv)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 443, in execute_from_command_line

utility.execute()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 382, in execute

self.fetch_command(subcommand).run_from_argv(self.argv)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv

self.execute(*args, options.dict)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute

output = self.handle(*args, options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle

return self.handle_noargs(options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 110, in handle_noargs

emit_post_sync_signal(created_models, verbosity, interactive, db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/sql.py", line 189, in emit_post_sync_signal

interactive=interactive, db=db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send

response = receiver(signal=self, sender=sender, named)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 73, in create_superuser

call_command("createsuperuser", interactive=True, database=db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 150, in call_command

return klass.execute(*args, defaults)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute

output = self.handle(*args, options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 70, in handle

default_username = get_default_username()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 105, in get_default_username

default_username = get_system_username()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 85, in get_system_username

return getpass.getuser().decode(locale.getdefaultlocale()[1])

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 503, in getdefaultlocale

return _parse_localename(localename)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 435, in _parse_localename

raise ValueError, 'unknown locale: %s' % localename

ValueError: unknown locale: UTF-8
ankbansa-MacBookPro:acdb ankbansa$ python manage.py syncdb
Creating tables ...
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
ankbansa-MacBookPro:acdb ankbansa$ rm -f resources/sqlite.db
ankbansa-MacBookPro:acdb ankbansa$ python manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table resultEntry_testcase
Creating table resultEntry_buildinfo
Creating table resultEntry_result
Creating table django_admin_log

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Traceback (most recent call last):

File "manage.py", line 10, in <module>

execute_from_command_line(sys.argv)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 443, in execute_from_command_line

utility.execute()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 382, in execute

self.fetch_command(subcommand).run_from_argv(self.argv)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv

self.execute(*args, options.dict)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute

output = self.handle(*args, options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle

return self.handle_noargs(options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 110, in handle_noargs

emit_post_sync_signal(created_models, verbosity, interactive, db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/sql.py", line 189, in emit_post_sync_signal

interactive=interactive, db=db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send

response = receiver(signal=self, sender=sender, named)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 73, in create_superuser

call_command("createsuperuser", interactive=True, database=db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 150, in call_command

return klass.execute(*args, defaults)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute

output = self.handle(*args, options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 70, in handle

default_username = get_default_username()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 105, in get_default_username

default_username = get_system_username()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 85, in get_system_username

return getpass.getuser().decode(locale.getdefaultlocale()[1])

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 503, in getdefaultlocale

return _parse_localename(localename)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 435, in _parse_localename

raise ValueError, 'unknown locale: %s' % localename

ValueError: unknown locale: UTF-8

This error message is wrong , showing error "unknown locale: UTF-8" to the user , conveys that the user has entered\put something wrong which is not the case here.
I facing the error for the first time . I have used Django on Pc but this my first experience of Django on Mac OSX (10.8.2) .

Please let me know in any case i can help .

[Ramiro Morales]

Replying to ank.bnsl@…:

Please let me know in any case i can help .

Yes, one very useful piece of data would be what version of Django you are using.

The fix is available in the soon to be released 1.5. According to our work flow we mark a ticket fixed on this tracker when it has been fixed in the in-development version and not all of these fixes get applied to the already-released version (currently 1.4.x).

Unfortunately if you are using 1.4.x (latest stable release) you won't get this fix and will have to look for workaround/fixes provided by your OS.

Another option would be to start your exploration of Django by installing the first release candidate of 1.5.