pipsi installs into isolated virtualenvs, then symlinks into `~/.local/bin` just like `pip install --user`. Combining pipsi for cross-project tools (tox, twine, nox, etc.) with pipenv for project-specific packages is all you need. You don't need to `pip install --user` some package at that point.
>>> Want to use python3? That's cool, use the flexible environment. But it doesn't support taskqueues or many other features.
As far as I know there is no planned support for Python 3 in the standard env. I've been using GAE since 2010 but I'm a little uncomfortable continuing to writing new apps in Python 2.7 when they have a clear end of life date set now.
Given it might take you guys a year or two to support 3 after you decide to do it, then a year or two for me to port my apps over to python 3, my apps might be running for a while past the end of life date for Python 2.7.
Besides, I can't just keep writing 2.7 apps forever, so either I you guys have to update the SE to 3, or I need to start evaluating and comparing the flexible environment to what everybody else offers.
We are indeed working on creating a standalone Task Queues service that will work across all hosting platforms. You can sign up for the alpha here: https://goo.gl/Ya0AZd
(I work on the Python developer experience for Google Cloud Platform)
This is why I come to HN. Where else can you read an article about a high profile company, then find comments from people who work on what the article is about? Unless you guys are a brigade, it's pretty cool you happen to be browsing where the rest of us browse.
You can use Postgres and Redis. :) I'm working on writing new tutorials for both of those, but in the meantime:
You can host your own Postgres on Compute Engine [1] or use a hosted provider like ElephantSQL [2]. You can use whatever client library you want to connect to postgres in App Engine flexible.
Same story for redis - you can host it on Compute Engine [3] or use something like redislabs.
that's not the same as fully managed postgresql (which only aws has (at the time))
elpahntsql is not really cheap compared to aws master-slave.
Just comparing the smallest instances, elephantsql:
- db.t2.micro 1 year 20 USD / month (250 USD upfront) - 24.82 USD monthly (that's a multi-slave with auto failover)
compared (with 30gb (SSD) storage it's at 30 USD) to elephantsql only 2GB data on a shared database server 20 USD
- db.t2.small 1 year 41 USD / month (500 USD upfront) - 50 USD monthly (that's a multi-slave with auto failover) (with storage around ~60 USD) vs elephantsql Happy Hippo single dedicated database 99 USD 100gb data
you kidding right? I would need to pay twice the price.
Redis is provided by Click to Deploy, i.e. "Popular open stacks on Google Compute Engine packaged by Google", and is in beta (Estimated costs: $307.80/month).
Looks like Redis Labs has a trivial free tier, and the 1GB plan is cheaper on GCE than AWS ($57/mo vs. $71/mo). I'm pretty annoyed that I had to create a Redis Labs account to see that though.
How do you deal with securing the DB's in this setup? Is it possible to isolate the compute engine DB ports to only your appengine instances, or do they have to be open to the whole world?
App Engine Flexible runs on GCE instances, which all have internal IPs. So you can just firewall off external traffic but allow internal, which is the default anyway.
Global GCE instances within your project, yes. Not every GCE instance everywhere, that would not be very helpful :)
If you wanted to have some instances that couldn't talk to your database, easiest thing to do is probably throw them in a separate project or create a new subnet that you firewall off and create your non-App Engine instances in that subnet.
> Google App Engine's dev_appserver.py completely broke after an update, caused in part by another Google library being installed (protobuf...). Still not sure if the fix was rolled into a release yet...
We've been having a lot of fun with how tricky namespace packages are in Python. We've got a fix in for this issue that should hopefully be in the next SDK release, and we're looking into ways to better isolate dev_appserver from the OS environment.
A simple workaround is to activate an empty virtualenv before running dev_appserver.
I tried to move beyond archaic Java with managed VMs when they were first announced. Back then it was half-baked and glitchy, it felt like Google was using its actual users to do their testing, I hope it's gotten better since.
Generally, I think what Google is missing (or doesn't care about) is that anyone who is using a PAAS provider is willingly exchanging some flexibility, control, and price-efficiency for the luxury of having devopsy management tasks taken off their hands in a competent and reliable manner. Managed VMs seem to be providing so little of that that you might as well move to IAAS. Or, do as I have, and move to Azure - who do manage to stay pretty current, and blend PAAS and IAAS in a much more elegant manner.
> I tried to move beyond archaic Java with managed VMs when they were first announced.
Please keep in mind that Managed VMs is still in beta, however, there are other parts of Google Cloud Platform that are in GA, including Compute Engine (IaaS), and Container Engine (somewhere between PaaS and IaaS). In fact, depending on how much control you want, Container Engine can be a better fit than App Engine.
