Latest version of Werkzeug raises ImportError

[awonak]

The latest version of Werkzeug (0.13) released on December 7th raises an ImportError when Flask is imported on app engine.

ImportError: cannot import name SpooledTemporaryFile

App engine standard does not support SpooledTemporaryFile, so we should explicitly instruct users to install Werkzeug==0.12.2 (last working version).

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[googlebot]

CLAs look good, thanks!

[theacodes]

To prevent our auto-updating script from messing with this, can you change it to a range? (& also add a note as to why we pin it)

Werkzeug<=0.13

[theacodes]

Do you mind filing a bug on Werkzeug for this?

[theacodes]

Thanks, @awonak!

[awonak]

There is an issue over in Werkzeug. If they do revert back to TemporaryFile we should update the changes here to pin to that update.

[davidism]

Is there a reason SpooledTemporaryFile isn't supported? It simplified code we were using, is part of the standard library, and supporting GCP means adding back the workaround. I'm not familiar with GCP, so every time something breaks it's non-trivial to investigate and test this. Is there a better way we can be testing against GCP, similar to Travis-CI?

[davidism]

I read https://cloud.google.com/appengine/docs/standard/python/runtime#customized-libraries-in-python-version-27. Is there a way for GCP to more comprehensively monkeypatch the tempfile module instead of restricting what can be imported?

[theacodes]

@davidism thanks for jumping in. :)

Is there a reason SpooledTemporaryFile isn't supported?
Is there a way for GCP to more comprehensively monkeypatch the tempfile module instead of restricting what can be imported?

App Engine Standard is heavily sandboxed and currently blocks all access to the filesystem. It's technically possible that we can emulate that with an in-memory file, but doing such changes is really difficult for us at the moment.

We're working on some under-the-covers changes to our runtime environment that will make it easier for us to get closer to a unforked experience and those will hopefully land early in the new year, so, if you want to say "no", that's perfectly acceptable.

Is there a better way we can be testing against GCP, similar to Travis-CI?

The rest of GCP (App Engine flex, GCE, GKE) is fine it's just the sandboxed standard environment. I helped set up testing against GAE standard for urllib3 and I'm happy to do the same with Werkzeug if you want- but this is another case where it might be better to just wait for our changes that fix some of the deviation from the standard library (ideally, if it passes generic Python 2.7 it should work in GAE standard).