Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set locale for tests #2368

Merged
merged 1 commit into from Sep 3, 2013
Merged

Set locale for tests #2368

merged 1 commit into from Sep 3, 2013

Conversation

mdboom
Copy link
Member

@mdboom mdboom commented Sep 3, 2013

This fixes the part of #2343 related to the date strings not matching the baseline images. Since the baseline images were created (by me) in the en_US.UTF-8 locale, we should run the tests in that locale, too, so the output files will match the baseline images.

… during tests so that the output will match the baseline images
mdboom added a commit that referenced this pull request Sep 3, 2013
@mdboom mdboom merged commit 8d468f9 into matplotlib:v1.3.x Sep 3, 2013
@Arfrever
Copy link

Arfrever commented Sep 4, 2013

locale.setlocale(locale.LC_ALL, 'en_US.UTF-8') will fail with locale.Error: unsupported locale setting if en_US.UTF-8 locale is not available on user's system.

@mdboom
Copy link
Member Author

mdboom commented Sep 4, 2013

I'm not sure if there's a way around that. We have to create tests in some locale. If this means that the small fraction of users (mainly developers) who run the tests have to install the en_US locale, I think that's fine.

I tried using the "C" locale, but I don't know if that guarantees English month names.

@cgohlke
Copy link
Contributor

cgohlke commented Sep 8, 2013

A lot of tests fail on Windows because en_US.UTF-8 is not available (http://msdn.microsoft.com/en-us/library/hzz3tw78%28VS.80%29.aspx). Using English_United States.1252 works for me and all tests pass.

@efiring
Copy link
Member

efiring commented Sep 8, 2013

@cgohlke, That doesn't work on linux or OS X, so I imagine the idea would be to use a try/except to use it if en_US.UTF-8 fails.

@cgohlke
Copy link
Contributor

cgohlke commented Sep 8, 2013

Sure, neither en_US.UTF-8 nor English_United States.1252 are cross platform. I just meant to report that the latter works on Windows.

@dmcdougall
Copy link
Member

@cgohlke Looks like we'll need to some conditional logic on the output of sys.platform to set the appropriate locale for each platform. Unless there's a better approach I'm not thinking of (e.g. the existence of a cross-platform locale).

It looks like, for Windows, sys.platform could return win32 (and probably win64 too?) or cygwin.

@efiring
Copy link
Member

efiring commented Sep 8, 2013

On 2013/09/08 11:38 AM, Damon McDougall wrote:

Looks like we'll need to some conditional logic on the output of
|sys.platform|

Why not just try the one that is there now, and if that fails, use the
Windows version? I don't see any point in putting in logic.

@cgohlke
Copy link
Contributor

cgohlke commented Sep 8, 2013

en_US.UTF-8 works on cygwin too. I'm OK with both, try:...except: or if sys.platform == 'win32'.

@dmcdougall
Copy link
Member

Why not just try the one that is there now, and if that fails, use the
Windows version? I don't see any point in putting in logic.

Oh, I'm fine with that solution too, I was just being cautious about locales working on different platforms. I had no idea whether en_US.UTF-8 worked on cygwin, that's all.

en_US.UTF-8 works on cygwin too. I'm OK with both, try:...except: or if sys.platform == 'win32'.

Ok, I'll patch that up and open a pull request. Thanks for taking the time to investigate.

@mdboom
Copy link
Member Author

mdboom commented Sep 9, 2013

@cgohlke, @dmcdougall : What do you guys think of #2396 as a solution?

@mdboom mdboom deleted the test/set-locale branch August 7, 2014 13:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants