My website was built using Google AppEngine, DataStore and Python2.7. It’s no longer working This site can’t be reached. I need to migrate to Python3 but I cannot identify which migration guide is best suited for me. Can anyone point me to the correct set? I would like to get it running as quickly as possible (I only have one hour a day to try to correct it -- I have an unrelated full-time job).
Migration guide
Google provides a step-by-step migration guide especially for AppEngine which you should follow.
Additionally, you will find lots of useful links there where you can read about the differences between Python 2 and Python 3 and the various migration tools available. Depending on your application those tools might even be able to do the migration (more or less) automatically for you.
Please note: This is the migration guide for the AppEngine standard environment. If you don't know what you're using, you're most likely using the standard environment. While some steps will differ when using the flexible environment, migration of the code base as described in the guide will always be required.
Video: Python 2 to 3: Migration Patterns & Motivators (Cloud Next '19)
There also is a recording of a talk by the Google Cloud Team on migration from Python 2 to 3 on YouTube.
Still having issues?
Migrating from Python 2 to 3 is a well-known problem and there is tons of information available on the internet. Most likely the problems you face have already been solved by someone, so a Google search for a specific problem will likely give you a working solution.
Related
I'm with a dilema here about which SE site to ask this question so please help me out if it should be somewhere else.
I've been looking into Infrastructure as Code solutions.
Didn't like Terraform too much. The lack of intellisense makes discoberability harder than programmers have been used to.
I've been considering ARM templates. I like it that the templates are made available as we create resources in the portal but it seems way less readable and harder to maintain afterwards.
Then I found out Pulumi and love their idea compared to Terraform. The way I see it, they're approach is also declarative like the above options but we can use decent programming languages to get the job done.
The for loops is a must.
Cool, I like that! But since we like using C# (or other alternatives), then why don't we SDKs to manage our infrastructure as code?
Pulumi has compared themselves with cloud SKDs by positioning their solution as much safer advocating that, if we just use a cloud SDK ourselves, then our solution wouldn't be that reliable.
To what extent is this really true, I wonder?
Last year, I wrote some libraries that used Azure service bus queues/topics. There were several integration tests that would run in parallel and I needed to isolate them by creating new queues/topics and used Microsoft.Azure.ServiceBus.Management.ManagementClient to do this.
It really didn't seem like I had to learn anything at all.
Going to the point now. Not discarding Pulumi's innovation which I think is great:
Will Pulumi's really add that much benefit compared to using Azure SDKs?
What's been your experience with it?
A Pulumi developer here, so I'm definitely biased. I suspect the SO community may find your question violating some of the guidance, but I hope my answer survives :)
One upside of using Pulumi is that you get access to multiple providers with consistent developer experience. You may be using exclusively Azure, but you might at some point start combining it with things like building and publishing Docker images, deploying Kubernetes applications, or Datadog dashboards. All can be done from the same program or solution.
Now, the biggest difference with imperative SDKs is the notion of desired-state configuration. A Pulumi program describes the graph of resources and dependencies between them (what), not the steps to provision them (how). When you have an environment that lives for months and years, there's a big difference between evolving a single definition with baby steps and applying incremental changes (Pulumi) and writing a bunch of update scripts/programs to bring each environment to the new state (SDK).
How do you maintain multiple environments that may be similar but still different? (production vs staging vs test vs dev) How do you make sure that your short-lived infra that you created for nightly tests reflects the reality of production? What happens when an SDK program fails in the middle - can you retry running it again or will it create duplicate resources/fail with another error? How do you get a simple overview of changes over time in git? Concurrency control? Change history?
All the things above are baked into Pulumi and require manual consideration with a cloud SDK.
I see that no active development is going on from vogels page from a long time i.e, about 5 months https://github.com/ryanfitz/vogels
Are there any better options?
Has anyone faced issues with scalibility or I/O time with it?
I've been using vogels on a project recently. While it seems like it isn't as well maintained as it used to be, it's still quite a nice API wrapper - certainly much nicer than using the SDK directly.
I haven't encountered any performance cost with it - it's really just assembling AWS SDK calls, and doesn't do anything too crazy. The code is simple enough that anything I was unsure about I can dive in and check it out, and the docs are pretty good.
However another option that I've found recently is this library, open sourced by Medium. It's promised based and looks well maintained:
https://github.com/Medium/dynamite
I've been using Vogels for around 6 months now and it's done everything I've needed it to do. The raw dynamoDB api is too low level for what I need. I too noticed that the module wasn't being 'maintained' so I created a fork of the project and republished it to npm:
npm
github
I'm actively working on it to bring it up to modern standards and looking for more contributors to help out.
I like a lot Cucumber and I find a very useful tool to solve problems seeing them with an outside-in approach so I would like to use it as part of chef projects too. I have successfully integrated it into the project I'm working on but at the time of writing business goal of features I have some doubts.
Who is the end user here?
Regarding on this the feature will be more service oriented or not, ie:
If the feature is more architecture faced the I could write a MongoDB feature which describes that I need up and running a MongoDB service and that the applications is linked to it.
In the other hand I should just write application features, forgetting about the infrastructure behind and then assume that if the cucumber tests run well for the application then it means that the infrastructure is fine too. (I dont like this approach)
Which of the both approaches are better? I like the most the first one but I'm just a noob on these lands. Please give me your considerations.
I'm writing an application in Node.js for a spare-time, bootstrap project. I have a Windows background and Windows Azure with three-month free trial currently seems like the simplest way to develop, deploy and host the project.
However Windows Azure appears to get expensive after the free trial expires, and in any case I'd like the option to host on non-MS platforms, so I have a couple of questions:
I can see from the tutorial that I need some Windows-specific code to import the port number at which the app should listen - are there many more examples of Windows or Azure specific code requirements further down the line?
I'd like to take a NoSQL approach to data storage since I'm more interested in flexibility and performance than in referential integrity or structural consistency - would it be difficult to wrap Azure Tables in a data access layer that would be reasonably portable to other NoSQL databases such as MongoDB or the various cloud offerings?
Finally, the catch-all question - is there anything else I should be looking out for?
Tackling your second question: there are modules in the NPM registry that can help you here.
Firstly Microsoft have recently released the Azure SDK for node as an NPM installation module. This has a rich API that will help you interface into Azure Tables.
There are also NoSQL clients available in the NPM registry for most solutions (including MongoDB).
If you keep your data access simple, you should be able to make use of the various NoSQL clients that are available and create a nice little module layer that sits above all the ones you need to support.
You could even create a public github repository and submit your hard work into the NPM registry for other people to help you develop.
I have built an app on Windows Azure's node.js support as well and there is virtually no lock in if you stick to npm modules and open platforms.
You should also check into Microsoft's Bizspark program - you get two years of 2 reserved instances for free + storage. Its a great program.
I wanted to try cloud computing.
I went to PythonInfo Wiki and found links to Google App Engine and PiCloud (which uses Amazon Web Services). However, it turns out that neither of them supports Python 3 (at least at first glance). I would hate to port my code back to Python 2.7.
Does anyone know if there's an easy way to use cloud computing in Python 3 (I don't care who the provider of computing power is)?
With apologies for the self-promotion, my company are working on a cloud-based python environment. We should be able to support all flavours of Python. More info here:
http://www.pythonanywhere.com/