--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/eff3cf33-3a7b-4cc4-8b8c-2a46b2c56c45%40googlegroups.com.
I would recommend trying to solve the first problem and serving static files locally.
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/BJDE8y2KISM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CANtYgF%2BPRh3vU%3Dpp3708sRAFE8%2BYxC%3Dm%2BmC8oGVqHyLw3yKBhw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CA%2BcaGh-8rd4NVj2HmcS0t0PRAAJ%2BiWo3huzjXcbJSDxyJtsAPw%40mail.gmail.com.
That does make sense. If you could bridge the gap by using a single static file directory in app.yaml served with a single static_dir handler, that might work too. But I know some apps have very complex app.yaml defined static files, so I understand why you're looking at the dev_appserver.py option instead.
On Fri, Nov 8, 2019 at 3:33 PM Ryan Barrett <ry...@barrett.name> wrote:
thanks for the reply!
On Fri, Nov 8, 2019 at 2:40 PM 'Andrew Gorcester' via Google App Engine <google-a...@googlegroups.com> wrote:I would recommend trying to solve the first problem and serving static files locally.understood, but using a different static file server is not great. it makes local development diverge significantly from production. local no longer uses or tests app.yaml's static file handlers, but prod does, so bugs will eventually pop up that only happen in production, and are thus harder to test for and debug.for that reason, i'm actually going the other way and using dev_appserver right now, soi still have some confidence that my app will behave more or less the same in production that it does locally. the minute long delay on startup is definitely painful though.
At first glance I think the most straightforward ways to do that would be to either:- Use the Flask development server instead of gunicorn and leverage Flask's integrated /static directory https://flask.palletsprojects.com/en/1.1.x/tutorial/static/- If you prefer to use gunicorn or you need more serving options, add WhiteNoise middleware to your app; ideally, have your app detect whether it's running in production or in development mode and conditionally add WhiteNoise in development only: http://whitenoise.evans.io/en/stable/
On Fri, Nov 8, 2019 at 2:21 PM Ryan B <goo...@ryanb.org> wrote:
--Hi all! My Python 3 topic for the day is local development. How are you all doing it? Any tips?The two main ways seem to be a third party server, eg Flask or Gunicorn, or dev_appserver.py. I have both working, but each one has a fatal flaw that makes it basically unusable for me so far.When I run my app with eg gunicorn -b :8080 app:application - the way Google recommends - it works, but doesn't serve any assets from static file handlers in my app.yaml. This is widely reported on StackOverflow and elsewhere. Responses are often some variation of, "why do you need static assets for dynamic requests?" The obvious reason is that pretty much all webapps use images, CSS, and/or JS, among other static files. They're generally not usable without those assets.When I run my app with dev_appserver.py, it creates a new virtualenv and installs all of my dependencies from requirements.txt. This is nice, but also extremely slow for any nontrivial app. My current medium sized app has 155 packages, and even when they're all cached locally, installing them takes around 60s. I often switch between different apps and other stacks, so I can't often keep dev_appserver running for hours or days on end to avoid this. (I've filed this feature request for dev_appserver to reuse an existing virtualenv.)Let me know if you have any ideas!
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-a...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/eff3cf33-3a7b-4cc4-8b8c-2a46b2c56c45%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/BJDE8y2KISM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-a...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CANtYgF%2BPRh3vU%3Dpp3708sRAFE8%2BYxC%3Dm%2BmC8oGVqHyLw3yKBhw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-a...@googlegroups.com.
patch /opt/homebrew-cask/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/instance_factory.py ~/dev_appserver.virtualenv.diff
diff instance_factory.py.orig instance_factory.py
105,106c105
< if os.path.exists(venv_dir):
< shutil.rmtree(venv_dir)
--
> pass
120,121c119,124
< self._CleanUpVenv(self._venv_dir)
< self._venv_dir = tempfile.mkdtemp()
--
> self._venv_dir = os.path.join(os.path.dirname(self._module_configuration.config_path), 'local3')
> self.venv_env_vars = {
> 'VIRTUAL_ENV': self._venv_dir,
> 'PATH': ':'.join([os.path.join(self._venv_dir, 'bin'), os.environ['PATH']])
> }
> return
understood, but using a different static file server is not great. it makes local development diverge significantly from production. local no longer uses or tests app.yaml's static file handlers, but prod does, so bugs will eventually pop up that only happen in production, and are thus harder to test for and debug.