Hello Alex, >From your description, you’ve decided not to version your requirements.txt in Python. This is not a crazy approach but there are alternatives. I’m assuming you’re using App Engine Flex. I was able to find a document here <https://stackoverflow.com/questions/55052434/does-python-requirements-file-have-to-specify-version> that describes that you do not need to specify a version but indicates why it would work in some cases. The following information that I found highly suggests using a virtual environment in Python.
It reads: Specifying a version is not a requirement though it does help a lot in the future. Some versions of packages will not work well with other packages and their respective versions. It is hard to predict how changes in the future will affect these interrelationships. This is why it is very beneficial to create a snapshot in time (in your requirements.txt) showing which version interrelationships do work. There is an approach for best practices in this thread regarding your concern of breaking change in a package update and explains virtual environments: it's a good idea to get into the habit of using virtual environments to avoid dependency issues, especially when developing your own stuff. Anaconda offers a simple solution with the conda create command, and virtualenv works great with virtualenvwrapper for a lighter-weight solution. Another solution, pipenv, is quite popular. There is further explanation: A tip - you should aim to be using a virtual environment for each individual project that you'll be working on. This creates a 'bubble' for you to work within and to install specific package versions in, without it affecting your other projects. It will save you a lot of headaches in the future as your packages and versions will be kept project specific. There is a way in this thread <https://stackoverflow.com/questions/22944861/check-if-requirements-are-up-to-date> on how to check if the packages in your requirements.txt are up to date. You may choose to act on them as described. $ pip list --outdated You have described how you are working with three projects to implement your non-versioning scenario on Google Cloud Platform but I am unclear about your question. Can you tell me more about how you are validating the application and building to production so I may research? On Wednesday, January 6, 2021 at 11:32:13 AM UTC-5 Alex wrote: > Hi all, > > Would love to hear your views on this. I run a Python app on GAE. I have > quite a few packages in my requirements.txt file, and I made the choice to > not version them. Which I understand means the latest version of each > requirement at the time of the project build will be used. > > • Is that a crazy approach? I feel like I would not otherwise make the > effort of tracking packages updates and changing versions numbers. > > It of course raises the issue of possible breaking change in a package > update - and that happened to me already. > • I'm looking for best practices on how to mitigate that. > > I'm using three different projects for my app: one is a dev environment, > and I have a staging and production project. > > I would ideally like to keep requirements non-versioned in dev, but to > freeze a version for staging and prod. So that I don't get into the > situation where I may have validated the app in staging, then build to Prod > with a significant package change. > > • What approach would you suggest? I'm looking for something I can > automate - as I'm already using CloudBuild automation to build and deploy > in staging and prod. > > > thank you > > > -- 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-appengine+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/e1f6f329-7faf-4d5a-9d26-461255609c33n%40googlegroups.com.
