Install Pillow together with the rest of our CI deps

[ISSOtm]

We shouldn't assume how the user wants to install things. In particular, --break-system-packages seems... egregious.

This however breaks the MinGW testing workflows. That could be fixed by installing all deps there, but it sounds more worthwhile to install only Pillow there (it's a minor waste to install it on the MinGW builders, so we don't need the reverse option). I'm open to implementation strategy suggestions.

[Rangi42]

I agree we shouldn't be passing --break-system-packages in a script we intend users to run. I disagree with moving test-only deps into the rgbds deps script -- rgbds doesn't depend on Python at all, let alone the Pillow package.

Would it work to replace python3 -m pip install --break-system-packages pillow with py -3 -m pip install pillow in the fetch-test-deps.sh script, retaining its --get-deps flag?

Alternatively, we could special-case in the run-tests.sh script to set PY for libbet to tell it to use some non-system Python which has Pillow installed.

[ISSOtm]

I disagree with moving test-only deps into the rgbds deps script -- rgbds doesn't depend on Python at all, let alone the Pillow package.

I disagree on it being “the RGBDS deps script”, and see it instead as “the script that grabs what's not already available in CI”: for example, we do get PIL, but not Python itself. Being in .github, that script is meant to be CI-only, thus users (including packagers) don't care about it. Following that, I don't see a point in segregating build and test deps if we're going to need both.

Would it work to replace python3 -m pip install --break-system-packages pillow with py -3 -m pip install pillow in the fetch-test-deps.sh script, retaining its --get-deps flag?

Why are we fetching Pillow and not Python there? Possibly there are also other implicit dependencies (coreutils or suchlike) that we'd need to check for also. IMO none of that should be our responsibility, and thus those shouldn't be in a user-facing script. We could try detecting whether Python, Pillow, etc. aren't installed... but, meh.

Alternatively, we could special-case in the run-tests.sh script to set PY for libbet to tell it to use some non-system Python which has Pillow installed.

Sure, but then we still need to install it from somewhere. (Also, we could just use a venv; but that's largely besides the point, and IMO overkill.)

[Rangi42]

Sure, as long as install_deps.sh is only to be used by our CI (unlike install.sh which currently gets included in the distributed archives) then installing test deps there makes sense too. As long as it's commented so we know which test repo requires it.

[ISSOtm]

install.sh is an odd one, because it's only used by our CI but for packaging/distribution purposes. Though #1941 (comment) wants to get rid of it anyway. Everything else is consistently “factored-out bit of our YAML commands”.

[Rangi42]

I'm open to implementation strategy suggestions.

@ISSOtm How about retaining the distinction between rgbds deps and test deps, even if a single install_deps.sh script handles all of them? So in addition to the OS and toolkit args, it could take an optional "stage/purpose/downstream" arg.

[ISSOtm]

Thank you!