Looking for upgrade assistance?  Skip to the bottom for more information.

Clearly, artificial intelligence is taking the world by storm.  It is evolving at a brisk pace and finding its way into every corner of business, academia, and programming. But, how useful is it really?

I took a simple Django / Wagtail site from Django 3.2 to 4.2 and from Wagtail 2.15 to 5.2, leaning on AI along the way. This post chronicles the ways in which AI sped up the upgrade process while also highlighting the ways in which it still lags behind some older tools – at least for the moment.

The State of the Production Server

I did some exploration of the current website and it seemed like a pretty simple affair.  I was surprised to find, however, that the project listed 48 dependencies, which seemed like a lot for such a simple website.  I asked ChatGPT for its opinion:

ME: I have a long list of dependencies for a Django project, but I think that they are not all used.  How can I know which ones I actually need?

CHATGPT: To identify unused dependencies in a Django project, you can use tools like `pipreqs` or `vulture`. `Pipreqs` analyzes your project's imports to generate a minimal `requirements.txt` file with the packages actually used. `Vulture` finds unused code, including imports, in Python projects. Running these tools will give you insights into potentially unnecessary dependencies. Remember to review the results carefully, as some dependencies might be used dynamically or in ways these tools can't detect.

That was interesting because I had never heard of "pipreqs" or "vulture".  I decided to try "pipreqs".  Although that project looks like it might no longer be under active development, it still gave me some useful feedback.  Specifically, the only packages it could see being used (according to "import" statements) were Django itself and Wagtail.

I decided to build a local version of the website, using only those two dependencies (plus a few others that I knew I needed) as a starting point.  Beyond the upgrade itself, there were a couple other aspects of the website that I wanted to change: I wanted to convert the project's now old-fashioned "requirements.txt" file to a "pyproject.toml" file for use with the Poetry package manager, and I wanted to swap out the Gunicorn wsgi server for our company-standard uWSGI.

Poetry

Installing Poetry on the production server - where it had never been installed before - was the first step in converting away from the "requirements.txt" file. I remembered that Poetry has its own special installation process, but not exactly what the steps were. Filling in highly specific knowledge gaps like this is where ChatGPT can really come in handy:

ME: How do I install Poetry on Ubuntu 20.04?

CHATGPT: To install Poetry on Ubuntu 20.04, you can use the recommended installer script from the official Poetry documentation. Open a terminal and run the following command:

$ curl -sSL https://install.python-poetry.org | python3 -

This command downloads the installer script and executes it with Python 3. After installation, you may need to add Poetry's `bin` directory to your `PATH` in your shell configuration file. For more detailed instructions and options, refer to the official Poetry documentation.

There was some additional back-and-forth regarding how to make the Poetry binary install in "/usr/local/bin", where it would be accessible to all users.  ChatGPT also helped with this:

CHATGPT: To install Poetry directly in `/usr/local/bin`, you can use the official Poetry installer script with an environment variable to specify the installation path. Before running the installer, set the `POETRY_HOME` environment variable to `/usr/local`:

$ export POETRY_HOME=/usr/local
$ curl -sSL https://install.python-poetry.org | python3 -

This directs the installer to place Poetry's binaries in `/usr/local/bin`, making it accessible to all users.

Now on to converting the "requirements.txt" file to a "pyproject.toml".  Was there a preferred way to do that?

ME: What's the best way to convert a requirements.txt file to a pyproject.toml file?

CHATGPT: The best way to convert a `requirements.txt` file to a `pyproject.toml` file for use with Poetry is to first initialize a new Poetry project using `poetry init` in your project directory. This command will guide you through creating a `pyproject.toml` file. Afterward, use `poetry add $(cat requirements.txt)` to read each line from `requirements.txt` and add those packages to the `pyproject.toml` file. This approach ensures that Poetry correctly resolves and adds dependencies to your project configuration. For more detailed instructions, please refer to Poetry's official documentation. 

So that's what I did.  This step was very useful, as I had never used "poetry init" to let Poetry create the ".toml" file for me.  I had always created them by hand, which can lead to spending time fretting over which bits of the file are needed, which are not needed but recommended, which are not needed for my particular project, etc.

Running "poetry.init" triggers Poetry to ask for some basic information about the project (name, version, author, etc.). Eventually it asks you "Would you like to define your main dependencies interactively?" 

Fundamentally, knowing or discovering which versions of packages are compatible with which versions of other packages is the lynchpin for a successful upgrade.  The hope was that some combination of AI tooling and Poetry itself would provide quick and actionable assistance. 

I admit I was a little disappointed in the interactive mode for adding dependencies.  If you give it a package with no version number, it then asks you to supply a version number.  If you don't supply one, it goes with the highest version it can find.  The interactive mode doesn't constrain its choices based on the versions of packages that have already been added, such as Django 4.2.

ChatGPT wasn't much help here either.  I asked it a question that I thought would be pretty easy for it:

ME: What is the highest version of Wagtail that will run under Django 4.2?

CHATGPT: For the highest version of Wagtail compatible with Django 4.2, you should refer to the Wagtail release notes or Wagtail's official documentation for the most accurate and current information.

Nonetheless, using "poetry.init" - as ChatGPT had suggested - was a good way to generate a starter "pyproject.toml" file which saved time.  From there it was a familiar process of sequentially squashing errors until the project ran locally.  By the end of the package upgrades, the "pyproject.toml" had grown to include ten dependencies in addition to Django itself, but was still well short of the 48 in the pre-upgrade "requirements.txt".

Changing from Gunicorn to uWSGI

Switching from Gunicorn to uWSGI necessitates changes to the NGINX config.  But I didn't know exactly what those changes had to be. ChatGPT wasn’t able to provide much assistance until I made my query more specific by explicitly adding the relevant lines of my NGINX configuration to the prompt.

ME: Here are some settings for my nginx "server.conf" for use with Gunicorn... What would be the equivalent values to use if switching from Gunicorn to uWSGI?

CHATGPT: To switch from Gunicorn to uWSGI, replace `proxy_pass http://app_server;` with `uwsgi_pass unix:///path/to/your/uwsgi.sock;` and change `proxy_set_header` directives to `uwsgi_param`, like `uwsgi_param Host $http_host;`. Ensure your `uwsgi.ini` configures uWSGI to create a socket at `/path/to/your/uwsgi.sock`. This sets up Nginx to communicate with uWSGI instead of Gunicorn. For more details, check the uWSGI documentation.

This was useful information, and it was good to be reminded that more specific queries often lead to more accurate answers. Keeping this in mind will make ChatGPT a more effective tool for us in the future, allowing it to provide targeted guidance both for project upgrades and other tasks.

Conclusion

ChatGPT was effective in helping me to shrink the number of explicitly named dependencies in this project, converting a "requirements.txt" file to a "pyproject.toml" file, and converting the production server to use uWSGI instead of Gunicorn.  I was able to take advantage of the power of ChatGPT with these tasks by prompting it with well-defined questions that have specific and widely known answers.  This saved time.

However, ChatGPT was not more useful than older tools (Google, Stack Overflow) when it came to the basic procedures of upgrading the website's packages.  The code failures I encountered after installing the upgraded packages were mostly due to changed import paths or minor changes in usage within Django or Wagtail, such as converting calls to "url()" to "path()" in a "urls.py" module or "notequal" to "!=" in a template. These kinds of failures are routine for any upgrade, and fixing them is only a matter of researching the new usage and implementing the changes.  I can imagine an AI-powered tool that, given a target version for an upgrade, sniffs out and recommends the corresponding changes to imports and usage, but at the time of writing this seems beyond the reach of ChatGPT.

This upgraded site was small and the process was fairly routine.  I believe ChatGPT could prove even more valuable in a more complicated upgrade scenario.  Time normally spent debugging an error using traditional methods or analyzing package internals by eye to discover the source of the problem could be minimized if not eliminated by using ChatGPT and other emerging AI tools. 

ChatGPT and tools like it will certainly remain part of our problem-solving process; their effectiveness will only increase as they evolve and as we grow more experienced in using them.

Need Upgrade Assistance?

Django 3.2 reaches its end of life in April 2024.  If your site is on this or an earlier version, please fill out this form and we will reach out and provide a cost and time estimate for your consideration.  No obligation.