Are there certain workflows missing from the repo that the checks are trying to find? The logs mention some files that are supposed to be in github-actions-v0.2 (linking to the directory at the last commit at the time of writing this) but in my fork and the upstream, it doesn't exist.

FWIW. The failing style checks (aside from some odd sort issues) are:

==> Running flake8 checks
[207](https://github.com/spack/spack/runs/6868076623?check_suite_focus=true#step:6:208)
==> Error: spack style found errors
[208](https://github.com/spack/spack/runs/6868076623?check_suite_focus=true#step:6:209)
var/spack/repos/builtin/packages/py-ford/package.py:12: [E501] line too long (117 > 88 characters)
[209](https://github.com/spack/spack/runs/6868076623?check_suite_focus=true#step:6:210)
var/spack/repos/builtin/packages/py-markdown-include/package.py:12: [E501] line too long (162 > 88 characters)
[210](https://github.com/spack/spack/runs/6868076623?check_suite_focus=true#step:6:211)
var/spack/repos/builtin/packages/py-markdown-include/package.py:21: [W293] blank line contains whitespace
[211](https://github.com/spack/spack/runs/6868076623?check_suite_focus=true#step:6:212)
var/spack/repos/builtin/packages/py-md-environ/package.py:12: [E501] line too long (108 > 88 characters)

Is the import statement being flagged in the style check just a result of some weirdness happening behind the scenes, or do I actually have to change it? I just used what was given when I ran spack create

Is the import statement being flagged in the style check just a result of some weirdness happening behind the scenes, or do I actually have to change it? I just used what was given when I ran spack create

Unfortunately, it has to be changed to pass the check. That command provides a template with things that need to be filled in or removed. If it's off then that needs to be adjusted. (I'll take a look.)

From the output of the GitHub action I can't really tell what change I need to make--do you have an example of what a correct import placement would look like? I thought it looked fine since I checked other packages and it looked similar, but maybe I missed something.

From the output of the GitHub action I can't really tell what change I need to make--do you have an example of what a correct import placement would look like? I thought it looked fine since I checked other packages and it looked similar, but maybe I missed something.

isort doesn't like the comment line containing the dash to appear before the import. The most consistent fix is to simply remove it. Most packages also retain only a single blank line between the License Identifier comment and the first import.

I can't tell why it's failing these tests. The only thing that I can understand is the line that says it can't find the package py-markdown-include, despite it being added in this PR. Any insight or help as to what is going wrong would be appreciated, because when I run spack unit-test locally I get a slew of different errors that don't show up here.

The python 2.7 checks remind me of some failures yesterday that were fixed. Can you rebase to develop? (One option is to click the Update branch here but then you'll have to git pull if you make any more local changes.)

The reason you're seeing your new packages in tests is that they are automatically pulled into some existing unit tests.

@adamjstewart @alalazo Do either of you know why this PR is having problems with the unit tests (esp. 2.7)?

No idea, but I'm seeing the same issue in #30916 so I would also love to know why.

P.S. Remind me to review the Python packages before this is merged.

P.S. Remind me to review the Python packages before this is merged.

Just added you as a reviewer. That should help. 😉

No idea, but I'm seeing the same issue in #30916 so I would also love to know why.

For some reason, the py-markdown-include package.py was in a UTF-8 charset when all my other package files were in ASCII. When I fixed it (see latest commit) then everything worked fine.