remove python dependency to simplify use in MFE build/deployment

[brian-smith-tcril]

Considering the goals of https://github.com/openedx/openedx-translations include no longer having translated strings checked in to individual repos, it makes sense to utilize atlas during the build/deployment process for MFEs. With this in mind, as discussed in OEP-58

Having atlas built in python adds complexity to the deployment of MFEs.

A few options were presented:

• Sticking with python and ensuring MFE build/deployment environments can run python
• Moving to bash
• Keeping python, also implementing atlas in js
• Removing atlas, creating .gzip releases on https://github.com/openedx/openedx-translations

After looking into these options, moving to bash seems to be the simplest way to ensure the functionality we desire from atlas is available in all the environments we expect to run it in.

[brian-smith-tcril]

one thing to consider with a move to bash is testing

i think a good path forward for that would be to utilize bats and bats-mock

[brian-smith-tcril]

another thing to consider is argument parsing, it seems https://argbash.dev/ should be a good way to handle that

example argbash template for parsing atlas args

#!/bin/bash
#
# openedx-atlas argbash (https://argbash.dev/) argument template
#
# ARG_OPTIONAL_SINGLE([config], , [path to alternative atlas.yaml configuration file])
# ARG_OPTIONAL_SINGLE([branch], b, [branch to pull], [main])
# ARG_OPTIONAL_SINGLE([repository], r, [repository to pull])
# ARG_OPTIONAL_SINGLE([directory], d, [directory to pull])
# ARG_POSITIONAL_SINGLE([positional-command-arg], [only one command is available: pull], )
# ARG_HELP([Atlas is a CLI tool that has essentially one command: \`atlas pull\`\n \nAtlas defaults to using a configuration file named `atlas.yaml` placed\nin the root directory. Configuration file:\n \npull:\n  branch: <branch-name>\n  directory <directory-name>\n  repository: <organization-name>/<repository-name>\n \nAtlas can also use a configuration file in a different path using the \`--config\` flag\nafter \`atlas\`: \`atlas --config pull\`.\n \nAtlas can also be used without a configuration file by using the flags below after\n\`atlas pull\`.\n \n\`-b\` or \`--branch\`\n\`-r\` or \`--repository\`\n\`-d\` or \`--directory\`\n])
# ARGBASH_GO

# [ <-- needed because of Argbash

echo "Value of --config: $_arg_config"
echo "Value of --branch: $_arg_branch"
echo "Value of --repository: $_arg_repository"
echo "Value of --directory: $_arg_directory"
echo "Value of positional-command-arg: $_arg_positional_command_arg"

# ] <-- needed because of Argbash

[brian-smith-tcril]

recommendation from @kdmccormick https://www.shellcheck.net/wiki/Home

ShellCheck is a static analysis tool for shell scripts. This wiki holds all the long form descriptions of warnings and suggestions it outputs. If you get this output:

[brian-smith-tcril]

i put together a proof-of-concept of this

the atlas side is here: https://github.com/brian-smith-tcril/openedx-atlas/pull/1, it includes a gh actions workflow that runs argbash and shellcheck, as well as a workflow that runs when a tag is pushed to create a release

on the MFE side of things, i put together a proof-of-concept on this branch of course authoring. this branch updates the pull_translations target in the makefile to download and run a specified release of atlas

things left to do for feature parity with the python version:

• automated testing

[brian-smith-tcril]

after looking over a bunch of different testing frameworks, i've decided to move forward using ShellSpec

my reasoning behind this decision:

• not tied to bash (tested across many supported shells)
• full of features https://github.com/dodie/testing-in-bash#detailed-comparision
• well maintained

(potential/subjective) downsides to this choice:

• i'm not the biggest fan of the BDD DSL
• it's only 3 years old

alternatives considered (why i decided against them):

• Bats (very bash focused)
• shUnit2 (not well maintained, missing a few QoL features)
• bash_unit (very bash focused)
• shpec (seems like a less feature-complete version of ShellSpec)