Fail when packages cannot be found

[kurtmckee]

This introduces a new error-on-missing-packages input, which defaults to true. This is a breaking change.

Currently, only the phrase "Package 'xyz' not found." is searched for in the output of the install. The documentation of the new input leaves room for additional reasons for a missing package to be added.

Closes #20

[jon-turney]

Thanks. I really appreciate the effort in implementing this! 🎉 .

Unfortunately, I think this is the wrong place to fix this. Ideally, we'd fix this in the installer itself, so that uses outside of this action can benefit from that functionality.

There's also another problem in that (as vaguely alluded to in #20 (comment)) the way the installer currently emits this warning is wrong and can lead to false positives here.

(For example, if package X is obsoleted by package X' and then removed, requests to install X are valid and satisfiable (X is a dependency satisfying name that X' provides ("a provide")), but the current implementation in the installer just checks if X is in the set of actual package names and warns that a package named X doesn't exist.)

[kurtmckee]

Ah, that's a good distinction. I was expecting this work to be useful in the case (like mine) where I request a specific Python version but it's no longer available.

For example, the python39 package will eventually disappear and be replaced with a newer version. An executable named python3 that's missing in the Cygwin bin path might exist elsewhere in the PATH, but it would not be the version I was expecting to execute, and that might be difficult to run down.

If this isn't the direction to go, I can close this PR.

[kurtmckee]

I've rebased on master and updated the README now that #46 has merged.

I'm not convinced that this is the wrong place to implement this check, and wanted to explain my reasoning.

I anticipate that the ergonomics of Cygwin installs in GitHub is somewhat more static. From my side, I saw recently that Python 3.9 was still the default Python, though it's recently become end-of-life, and will hopefully be replaced soon.

If I create a workflow that tries to install Python 3.9 (python39), I think that I would prefer to be informed by the Cygwin install action that Python 3.9 couldn't be installed. I'm anticipating that the alternative is to have unexpected behavior later in the workflow that would require deeper investigation, like

• broken caches for Python package downloads
• broken cached Python virtual environments
• not having a Python interpreter at all
• having the Windows GitHub runner's Python interpreter for Windows -- rather than for Cygwin -- filling in the gap and manifesting platform-specific differences

However, you've got significant experience and knowledge in this area! If my reasoning is shortsighted or not convincing for any reason, let's close this in favor of waiting for the installer to gain better error messages, or a new CLI option, or both.

[jon-turney]

(python39), I think that I would prefer to be informed by the Cygwin install action that Python 3.9 couldn't be installed.

Well, yes, of course. Ideally the installer would already be detecting this kind of problem.

However, given that I'm not optimistic about it growing that feature any time soon, yeah, there is some value in having this, and given that it already exists (and can be turned off, which somewhat addresses my concern about false positives), maybe applying it is the right thing to do.

I need to think about this a bit more.

[cclauss]

Huge +1 on the idea of the workflow failing on package not found. It is easy to waste time because this crucial error passes silently.