[merge] Handle bad LANG

[John Arbash Meinel]

Martin Pool wrote:
> On 24 Aug 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:
>> Right now if you set LANG to something unrecognized by python, you get
>> an ugly traceback.
>>
>> The attached patch changes bzrlib so it falls back to just using 'ascii'
>> after emitting a semi-helpful warning.
>>
>> I'm not 100% on the english of the warning, but I think it is reasonable.
>>
>> This is probably small enough for 0.10, but I'll let Robert decide.
> 
> I'd vote for it for 0.10.
> 
> I'd tend to call it 'locale' rather than 'LANG', both in the code and
> message.  That it's controlled by $LANG is a bit of an implementation
> detail.  (And I think on some other unixes it may not be $LANG?)  In
> particular on Windows is it $LANG that controls this?  If not the
> message may be confusing.  (Or perhaps this error can't occur.)
> 
> Even on Linux there are a bunch of LC_* variables which could influence
> this.

Yeah. Actually LC_ALL, LC_CTYPE, LANG, and LANGUAGE can all cause this.
I was trying to give an error that would at least point the users in the
right direction.

I haven't found any way to effect this on Windows (it is buried in the
_locale extension module, and I don't feel like digging through the
python source code at this point).

I agree, it should be 'test_locale'.:

...

>>    BUG FIXES:
>>  
>> +    * Handle when LANG is not recognized by python. Emit a warning, but
>> +      just revert to using 'ascii'. (John Arbash Meinel, 35392)
>> +
>>      * Active FTP transport now works as intended. (ghozzy, #56472)
>>  
>>      * Really fix mutter() so that it won't ever raise a UnicodeError.
>>
> 
> Just add a '#35392' so that we can grep for them.

Nice catch. I just missed the #. Funny because I'm usually pretty good
about it.

...

> 
> Since we're changing this, should we perhaps put it in osutils or
> bzrlib.locale, to keep the init file small?  (We would presumably need a
> deprecated property forwarding to the new one.)

I'm not sure how to do a property at module level. The standard
'property' function doesn't do the right thing. It seems they need to be
attached to a 'class' for them to actually function.

We can't have the module 'bzrlib/locale.py' because of python's import
issues (to be fixed in >2.5).

I feel like user_encoding probably needs to be defined fairly early on,
since it is necessary for command line argument parsing, etc. But I'll
put it into osutils for now.

> 
> If the intention is that the method be executed only once to initialize
> it, it should have an underscore.  Otherwise people will get the warning
> repeatedly.

Well, I was trying to figure out what the best thing would be. It would
be reasonable to deprecate bzrlib.user_encoding, though that wouldn't be
an 0.10 sort of change.

So I created a caching function in 'osutils', and then call it 1 time in
bzrlib/__init__.py


Oh, and the other problem is that we have to error check importing
locale, because Mac python doesn't do the right thing. (locale.py uses
backwards compatibility paths that aren't relevant anymore)


> 
> I'd suggest this message text:
> 
>   bzr: warning: %s
>   Could not determine what text encoding to use.
>   This error usually means your Python interpreter doesn't support
>   the locale set by $LANG (%s).
>   Continuing with ascii encoding.
> 
> Thanks
> 

See the updated attached patch.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: locale-35392.patch
Type: text/x-patch
Size: 25408 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060825/1c9fb3db/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060825/1c9fb3db/attachment.pgp