Day 18 - The Hirst Project, GitHub Workflows, and Package Management Woes

Day 18 - The Hirst Project, GitHub Workflows, and Package Management Woes

Part 2 - Tackling the Hirst Project while overcoming some annoying local issues


3 min read

Today's Objective

Today, I finished the second part of this module, which involved creating a mock Hirst painting. The project was fairly challenging but not mind-boggling; however, I encountered a few obstacles along the way. This article primarily discusses the issues I faced, serving as a reference for myself or anyone else who may encounter similar problems in the future.

Package Management Madness

So, starting the project was a pain since I had a lot of conflicting issues with the package managers I had installed on my local machine. This probably won't apply to most people using Python, but after exploring and trying out a bunch of different tools while getting into Python itself, I had a bunch of different managers (pipenv, conda, and miniconda) installed on my local machine. Within these package managers, I had various libraries installed, and when trying to access certain modules in my project, I kept getting "module not found" (specifically for I would try to reinstall, and it would say it's already installed. Just to provide context, this is how my list of environments looked:

Yeah... it's a mess ๐Ÿ˜….
Once I figured out my needed configurations and removed Anaconda completely (more on that later). I was able to get my modules working fine.

The Project

As mentioned in the intro, the project was to create a mock Hirst Painting. The fact that this man sold a painting that looked like this for over a million dollars is beyond me, but maybe I don't "get it" lol. Nonetheless, it's a bunch of random colored dots in a 10 x 10 square, stare in awe as you watch this masterpiece generate: Loom screen recording.
The code can be found here -> The reason the branch is no longer available to look at on remote was that I successfully created my first GitHub workflow to mimic repo management behaviors as I have at work, where we use Bitbucket.

New Github Workflow

The new workflow's job is to delete the remote branch after the pull request is merged. I have it set to also ignore this action if the branch is main or master. The code for this workflow is below:

name: Delete merged branch

    types: [closed]

    runs-on: ubuntu-latest
    if: github.event.pull_request.merged == true
      - name: Delete branch
        uses: actions/github-script@v6
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const { owner, repo } = context.repo
            const branch = context.payload.pull_request.head.ref
            console.log(`Deleting ${branch}...`)
            if (branch !== 'main' && branch !== 'master') {
                ref: 'heads/' + branch
            } else {
              console.log(`Not deleting ${branch} because it is a protected branch.`)

Settling on Environment

Circling back to the issues I had with pipenv and conda, I still plan to use conda in the long run, but pipenv is just so much lighter and I don't see myself needing a lot of the included tools and libraries that come with Conda at the moment. I will slowly start using miniconda first, then move to conda completely when I start to hit bigger projects during this journey.


So that wraps up Day 18 as a whole. Hopefully, people can take away a little bit of knowledge from this one regarding GH workflows and environment setups but ultimately, as you know from reading the first few articles, this is just a journal to serve as a resource for myself and if there are a few golden nuggets that people find helpful, then all the better โœŒ๐Ÿพ.

Did you find this article valuable?

Support Kyle Leonard by becoming a sponsor. Any amount is appreciated!