April: 09

Discord App Pitch

The docker build seems to error out for the Discord App Pitch 2024 game, so lets take a look at the error and see what we can do to resolve it.

The Docker build on action #1273 had this error: apps/express-colyseus-discord/src/rooms/MyRoom.ts:1:30 - error TS2307: Cannot find module '@colyseus/core' or its corresponding type declarations.

and then we went ahead and did the pnpm install @colyseus/core and then I will push this through and see what the next error might be.

There were a couple other errors, but that might have been either a typescript error because the the module was missing OR our typescript configurations might be wrong.

Yay! We were able to get the docker to build and publish, now its time to update the docker compose and add in our game files into the build process.

Charles

The new power supply is in and I will go ahead and swap it out.

If the power supply is not the issue then the bigger issue would be the amount of power that is coming out of the outlet, ugh, that would be terrible for us.

GHA

We need to update the Github Actions to perform test casing and integration testing across the board, but this might be a bit more painful than what I had expected.

Besides updating the actions to perform intergration testing, we also need to update the deprecated node v16 instances within our actions, bumping it up to node 20.

Part of this issue might be our node 18 usage as well, so going through all the code and making sure that we are using only node v20 as of right now.

Python

After we release a new python library version of atlas, we would want a function that gets called to help bump the version up by 0.0.1, so in our action we release version 1.0.3 and now we want it to automatically bump it up to 1.0.4.

For this situation, we can take a look at how we handle the cargo version bump and use that concept as a base for the automatic version bump.

Here is a base function that we can use to help do this!

# Function to bump the Python package version
bump_python_package_version() {
    local package_dir="$1"

    # Ensure the package directory is provided and exists
    if [ -z "$package_dir" ] || [ ! -d "$package_dir" ]; then
        echo "Error: Package directory is missing or does not exist."
        return 1
    fi

    local pyproject_file="$package_dir/pyproject.toml"

    # Ensure the pyproject.toml file exists
    if [ ! -f "$pyproject_file" ]; then
        echo "Error: pyproject.toml not found in $package_dir"
        return 1
    fi

    # Read the current version from the file
    local current_version_line=$(grep '^version = "[0-9]*\.[0-9]*\.[0-9]*"' "$pyproject_file")
    if [ -z "$current_version_line" ]; then
        echo "Error: Version line not found in pyproject.toml"
        return 1
    fi

    local current_version=$(echo "$current_version_line" | grep -oP 'version = "\K[0-9]+\.[0-9]+\.[0-9]+')

    # Increment the patch version number
    local base_version=${current_version%.*}
    local patch_version=${current_version##*.}
    local new_patch_version=$((patch_version + 1))
    local new_version="$base_version.$new_patch_version"

    # Replace the old version with the new version in pyproject.toml
    sed -i "s/version = \"$current_version\"/version = \"$new_version\"/" "$pyproject_file"
    echo "Version bumped in $pyproject_file to $new_version"
}

Now for us to execute this command, we have to add it into the shell command.

    -pythonbump)
        [ -z "$2" ] && { echo "No package directory specified. Usage: $0 -pythonbump [package_directory]"; exit 1; }
        package_dir="$2"
        bump_python_package_version "$package_dir"
        ;;

Finally, after the package is release, we will run:

./kbve.sh -pythonbump apps/atlas

Besides the version bumping, I am thinking of making a simple command that we can use to get started with python development, at least a bit faster.

Since the venv needs to be activated and based upon the different types of applications, it could get a bit messy, definitely with upgrading around it.

My solution would be to add a py flag within the kbve shell and have it handle it for us, hmm maybe it would look like this:

./kbve.sh -py atlas and then have it run these two commands:

source apps/atlas/.venv/bin/activate and then followed by code . to open it up in VSCode.

To do this setup, we will go ahead and add the python_venv_activate function:

python_venv_activate_and_run_vscode() {
    local directory_name="$1"
    local venv_path=""

    # Check the first potential path for the virtual environment
    if [ -f "packages/$directory_name/.venv/bin/activate" ]; then
        venv_path="packages/$directory_name/.venv/bin/activate"
    # Check the second potential path for the virtual environment
    elif [ -f "apps/$directory_name/.venv/bin/activate" ]; then
        venv_path="apps/$directory_name/.venv/bin/activate"
    else
        echo "Error: Virtual environment 'activate' script not found."
        return 1
    fi

    # Activate the virtual environment
    echo "Activating virtual environment from: $venv_path"
    # Use `source` to activate the virtual environment
    source "$venv_path"
    
    # Open Visual Studio Code in the current directory
    echo "Opening Visual Studio Code..."
    code .
}

Then under our custom flags, we will add the -py to the rest of the commands:

    -py)
        [ -z "$2" ] && { echo "No project directory specified. Usage: $0 -py [project_directory]"; exit 1; }
        directory_name="$2"
        python_venv_activate_and_run_vscode "$directory_name"
        ;;

So now we can just call the -py flag to help automatically setup the environments, making it easier for us to build and rotate around the different projects.