When Django 4.00rc-1, pipenv, djstripe and docker decide to pull the rug from under you

Sometimes you just need to rebuild your docker containers and that's where the problem started. When my containers came back, it wouldn't start because of a TypeError being thrown. 

  File "/usr/local/lib/python3.8/site-packages/djstripe/models/__init__.py", line 25, in <module>  
   from .core import (  
  File "/usr/local/lib/python3.8/site-packages/djstripe/models/core.py", line 30, in <module>  
   from ..signals import WEBHOOK_SIGNALS  
  File "/usr/local/lib/python3.8/site-packages/djstripe/signals.py", line 8, in <module>  
   webhook_processing_error = Signal(providing_args=["data", "exception"])  
 TypeError: __init__() got an unexpected keyword argument 'providing_args'  

Hmmm...

So I reviewed what was running on my docker containers. I had 4 containers: django with pipenv, celery, rabbitmq, and postgres. I ruled out postgres and rabbitmq out of the gate since the error is clearly a Python error. 

Focusing on the django container, I eventually found the error - took me the whole afternoon. At first I thought it was a docker bug but it wasn't. It was because of how pipenv was getting and installing the packages. Let me explain.

Our pipenv file that had django was set to install the latest version so it was written as django = "*". When I rebuilt the container and the dockerfile executed it downloaded the latest version of django which was 4.00rc-1.

The fix was to set the version: django = "~=3.2".

The moral of the story is don't blindly set your pipenv file to "*" and instead be explicit with the versions. Luckily pipenv does support semantic versioning meaning it will install minor versions of django 3.2 like 3.2.2 but not Django 4.0.

Updating powershell with powershell

To update powershell with powershell you, run the command: 

iex "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI"

That's it. 

I'm using Windows Terminal btw.

NOTE: This does not update the modules external to PS. You'll have to update those on their own.

Django tests on an Azure Pipeline

Source: https://gist.github.com/killertilapia/c9e7635807e596f20a16123ceed9c48d

Running Django tests on Azure is a mix bag of confusing documentation and outdated examples. When We did this I can't shake the feeling that Python was a second class citizen in Azure. 

Stuff that bugged me OR caught me flat-footed

1. Environment Variables. I get that having many options supported for declaring variables is cool but I wish Azure followed one of Python's tenets and that's "There should be one— and preferably only one —obvious way to do it.!". 

Another thing that bugged me was how Azure allows declaring variables for the pipeline: why allow a `.` (period) in the declaration then explain that gets replacement with `_` (underscore) and the rest of the text capitalized under certain conditions. 

Why couldn't we just stayed with YML? I never did like idea of "scripts within scripts". Again, Python's tenets: "There should be one— and preferably only one —obvious way to do it.!". 

2. vmImage version. This isn't really an Azure issue but more of a Python test issue. In order to run the tests I wanted: 

python manage.py test --testrunner xmlrunner.extra.djangotestrunner.XMLTestRunner --no-input --settings=settings.testing

I had to create an environment for the test to run on. So step before this was to install my environment prerequisites which is directly influenced by the vmImage version. At first, I was using: ubuntu-16.08 which was causing a Django migration error due to unsupported feature. We quickly figured out that the sqlite version that came with 16.08 was older. We also had to bump up the python version to 3.8. 

If you're basic and prefer to use a UI then Azure is probably your thing. But an old school guy like me who prefers automated scripts, Azure's documentation and philosophy to cloud is an inconvenience.