Skip to content
New issue

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

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

Already on GitHub? # to your account

environment can only contain strings #467

Closed
segalle opened this issue Dec 3, 2013 · 9 comments
Closed

environment can only contain strings #467

segalle opened this issue Dec 3, 2013 · 9 comments

Comments

@segalle
Copy link

segalle commented Dec 3, 2013

when running runserver_plus i get an error message: "TypeError: environment can only contain strings" (running on windows 7 x64).

i checked the list of the os.environ items and found out that CELERY_LOADER is unicode and not string.

i fixed it by changing this line to:
os.environ.setdefault(str('CELERY_LOADER'), str('djcelery.loaders.DjangoLoader'))

@hheimbuerger
Copy link

I got the same message exactly after upgrading celery from 3.0.24 to 3.1.8 and django-celery from 3.0.23 to 3.1.1.

@untitaker
Copy link
Contributor

I don't see how this is related to Werkzeug.

@hheimbuerger
Copy link

@untitaker As segalle said, it appears that werkzeug assumes all os.environ entries are byte strings (str), while some of them might be unicode strings. Now the question is whether that's an okay assumption to make—the documentation does not clearly state what type these must have.

I would suggest that werkzeug as an inspection tool is being made a bit more lenient here, however, and unicode strings support is added.

@DasIch
Copy link
Contributor

DasIch commented Aug 31, 2014

Werkzeug doesn't care about the type at all, subprocess however does. In fact there already is a workaround in Werkzeug that attempts to fix this problem in some cases https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/serving.py#L628

Nevertheless you shouldn't use unicode keys or values with os.environ. Using a non-ascii key or value will raise a UnicodeEncodeError which should be suggestion enough for this.

@untitaker
Copy link
Contributor

Should we close this then?

@hheimbuerger
Copy link

I think it's a problem that Werkzeug should work around, even if Celery is "at fault" in this case. At least until Celery fixes this. (Does anyone know if it has been reported to them?)

@hheimbuerger
Copy link

The problem seems to be this line: djcelery/init.py:20 in django-celery, together with the unicode_literals future import. See also: celery/django-celery#344

@untitaker
Copy link
Contributor

I don't think Werkzeug should silently work around this bug. A loop similar to https://github.com/mitsuhiko/werkzeug/blob/663e672a854bcfb10702dc54385d432a2f32707c/werkzeug/_reloader.py#L127 can be used before launching the server if you're using such broken libraries.

Also, which encoding would you use for this?

@untitaker
Copy link
Contributor

Closing this because it really is not a bug for Werkzeug to work around at.

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants